为 什么 要 写 这 本 书 


十 多 年 前 笔者 就 打算 写 一 本 Oracle 数 据 库 性 能 优化 方面 的 书 ， 屡 次 都 是 在 提 笔 写 了 几 行 字 后 就 放弃 了 。 近 几 年 ， 随 着 Oracle 数 据 库 的 普及 和 水 
平 的 不 断 提 高 ， 国 内 出 现 不 少 Oracle 数 据 库 方面 的 高 水 平 作品 ， 相 当 多 的 作品 都 涉及 了 性 能 优化 方面 的 话题 。 但 是 几乎 所 有 作品 都 只 是 讲解 了 性 能 
优化 相关 的 知识 和 经 验 ， 对 于 优化 思路 和 方法 很 少 涉及 。 作 为 性 能 优化 方面 的 “老兵 ”， 始 终 认为 优化 思路 和 方法 要 重 于 知识 和 经 验 ， 只 要 有 适当 
的 优化 方法 论 指引 ， 性 能 优化 甚至 可 以 成 为 Oracle 数 据 库 领域 相对 简单 的 业务 。 


近 几 年 ， 随 着 美 创 科技 公司 开创 并 实践 的 基于 流程 、 资 源 和 组 件 分 析 的 性 能 优化 方法 论 的 成 熟 ， 笔 者 比 以 往 有 了 更 大 的 动机 来 完成 本 书 ， 期 户 
它 可 以 在 Oracle 性 能 优化 史 甚至 整个 数据 库 性 能 优化 史上 留 下 印迹 ， 让 广大 的 Oracle 数 据 库 使 用 人 员 和 从 业 人 员 可 以 更 加 简单 地 完成 Oracle 性 能 优 
化 工作 ， 而 不 仅仅 是 个 别 高 级 DBA 的 专利 工作 。 


读者 对 象 


对 于 读书 ， 笔 者 始终 相信 一 本 书 只 要 有 几 句 话 可 以 对 读者 有 帮助 ， 那 么 这 本 书 的 价值 就 可 以 得 到 体现 。 作 为 优化 方法 论 类 相关 的 书 ， 一 般 阅读 
起 来 会 显得 枯燥 ， 尤 其 是 对 于 初学 者 ， 甚 至 可 能 会 比较 困难 ， 但 是 只 要 保持 耐心 ， 相 信 读 者 一 定 能 够 获得 收益 。 本 书 适合 以 下 读者 : 


: 中 高 级 Oracle DBA 
高 级 其 他 数据 库 的 DBA 
- 性 能 优化 从 业 人 员 
: 数据 库 架 构 设计 师 
' 数据 库 开 发 工程 师 
“ 容量 规划 工程 师 
“ 对 于 性 能 优化 保持 兴趣 的 数据 库 从 业者 


- 曾经 遭遇 性 能 障碍 的 数据 库 使 用 者 


如 何 阅读 本 书 
本 书 分 为 四 大 部 分 : 
第 一 部 分 为 漫谈 篇 (第 1~2 章 ) ， 简 单 地 介绍 了 性 能 优化 领域 的 一 些 特征 、 误 区 ， 以 及 性 能 优化 方法 论 的 发 展 。 


二 部 分 为 流程 篇 (第 3~4 章 ) ， 详 细 地 讲解 了 数据 库 登 录 和 数据 访问 处 理 流程 ， 该 篇 通过 流程 的 输入 和 输出 以 及 流程 分 解 来 描述 流程 ， 从 而 
帮助 读者 加 强 流程 认 知 ， 进 而 实现 流程 优化 。 


第 三 部 分 为 资源 (硬件 资源 ) 篇 (第 5~9 章 ) ， 分 别 讲述 了 CPU、 内 存 、Il/O、 网 络 等 硬件 资源 的 输入 和 输出 特征 ， 以 及 优化 的 主要 方法 。 


第 四 部 分 为 资源 (并 发 性 资源 ) 篇 (第 10~14 章 ) ， 分 别 讲述 了 队列 锁 、row cache lock, library cache lock, buffer lock, latch, mutex 
等 不 同 并 发 性 资源 的 作用 场合 、 输 入 和 输出 特征 ， 以 及 优化 的 主要 方法 。 

由 于 篇 幅 所 限 ， 优 化 方法 论 包含 的 重要 组 成 部 分 “组 件 ” 并 没有 包含 在 本 书 内 容 之 中 。 

建议 按照 顺序 阅读 本 书 ， 当 然 读者 如 果 仅仅 是 为 了 了 解 某 个 特定 领域 的 知识 ， 可 以 不 用 理会 本 书 的 章节 顺序 ， 选 择 自身 需要 的 内 容 阅读 即 可 。 
作为 优化 方法 论 类 图 书 ， 本 书 不 是 一 次 性 阅读 的 快 消 品 ， 需 要 多 次 阅读 。 由 于 本 书 在 某 些 地 方 涉及 了 一 些 其 他 作品 所 不 具备 的 细节 ， 也 可 以 作为 一 
本 案头 书 ， 必 要 时 可 以 查阅 。 


勘误 和 支持 


除 封面 署名 外 ， 美 创 科技 技术 服务 部 对 于 本 书 的 编写 提供 了 很 大 的 支持 ,特别 是 周亮 、 姜 宜 民 等 人 。 由 于 作者 的 水 平 有 限 ， 编 写 时 间 仓 促 ， 书 
中 难免 会 出 现 一 些 错误 或 者 不 准确 的 地 方 ， 朋 请 读者 批评 指正 。 如 果 你 有 更 多 的 宝贵 意见 ， 也 欢迎 发 送 邮件 至 邮箱 liuzl@ mchz.com.cn， 期 待 能 够 
得 到 你 们 的 真挚 反馈 。 
致谢 
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感谢 美 创 科 技 技术 服务 部 的 同事 们 ， 他 们 提供 了 大 量 的 性 能 优化 案例 使 本 书 内 容 更 加 充实 。 特 别 是 潘 敏 君 和 应 以 峰 ， 我 们 一 起 合作 完成 了 本 
书 。 特 别 感 谢 周亮 ， 每 个 章节 完成 后 他 都 在 第 一 时 间 进行 了 校对 和 纠正 ， 在 通 篇 完成 之 后 又 花费 了 大 量 时 间 来 进行 校对 和 修订 。 
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最 后 感谢 我 的 女儿 ， 是 她 时 不 时 地 几 句 “书写 完了 没有 ? ”让 我 抓紧 把 书写 完 ， 不 至 于 中 途 放弃 。 
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2015 年 9 月 于 中 国 杭州 


第 1 章 Oracle 性 能 优化 漫谈 


1.1 从 生活 场景 漫谈 性 能 优化 
Oracle 数据 库 性 能 优化 一 直 是 一 个 让 人 既 胆 层 又 兴奋 的 话题 ， 在 初级 DBA 腿 里 ， 这 是 一 个 神秘 的 领 吉 ， 即 使 是 资深 的 Oracle DBA， 也 可 能 无 


法 描述 清楚 性 能 优化 究竟 要 做 什么 ， 应 达成 什么 目标 。 那 么 性 能 优化 究竟 是 做 什么 的 呢 ? 简 而 言 之 ， 性 能 优化 就 是 让 我 们 的 工作 速度 变 快 ， 快 到 让 
我 们 满意 为 止 。 自 然 ， 又 有 读者 会 问 了 ， 我 们 的 工作 是 什么 呢 ? 什 么 程度 才 算 快 ， 是 否 可 以 衡量 ? 看， 头疼 的 问题 又 来 了 。 


第 1 章 Oracle 性 能 优化 漫谈 


1.1 从 生活 场景 漫谈 性 能 优化 


Oracle 数 据 库 性 能 优化 一 直 是 一 个 让 人 既 胆 性 又 兴奋 的 话题 ， 在 初级 DBA 眼 里 ， 这 是 一 个 神秘 的 领域 ， 即 使 是 资深 的 Oracle DBA， 也 可 能 无 
法 描述 清楚 性 能 优化 究竟 要 做 什么 ， 应 达成 什么 目标 。 那 么 性 能 优化 究竟 是 做 什么 的 呢 ? 简 而 言 之 ， 性 能 优化 就 是 让 我 们 的 工作 速度 变 快 ， 快 到 让 
我 们 满意 为 止 。 自 然 ， 又 有 读者 会 问 了 ， 我 们 的 工作 是 什么 呢 ? 什么 程度 才 算 快 ， 是 否 可 以 衡量 ” 看， 头疼 的 问题 又 来 了 。 


1.2 ”性 能 优化 目标 的 确定 和 衡量 


性 能 优化 ， 顾 名 思 义 就 是 一 个 改善 的 过 程 ， 通 过 这 个 过 程 实现 从 当前 A 到 B 的 目标 ， 其 中 A 和 B 必 须 可 以 被 描述 和 衡量 。 其 中 ，A 为 当前 状态 的 
描述 和 测量 。B 为 需要 达到 目标 状态 的 描述 和 测量 。 


很 遗憾 的 是 ， 在 现实 的 Oracle 性 能 优化 实践 中 ， 很 多 情况 下 A 和 B 不 可 描述 或 未 被 准确 描述 ， 只 知道 我 要 变 快 ， 而 且 是 尽 可 能 的 快 ， 最 终 使 性 
能 优化 变 成 一 锅 乱 炖 。 


大 家 都 知道 ， 性 能 优化 的 常规 目标 是 使 响应 速度 变 快 ， 但 快 和 慢 是 相对 而 言 的 ， 如 果 两 者 没有 一 致 的 描述 基准 ， 那 么 就 会 产生 问题 。 比 如 ， 如 
果 觉 得 现在 的 系统 速度 慢 ， 那 就 必须 先 弄 清楚 是 如 何 衡 量 速度 慢 的 ， 为 什么 这 种 状况 就 认为 它 速度 慢 了 呢 ? 以 一 个 电信 受理 业务 为 例 ， 客 户 反 馈 受 
理 很 慢 ， 需 要 进行 优化 ， 要 变 快 。 客 户 只 会 告诉 你 受理 慢 ， 不 会 告诉 你 更 多 ， 其 他 的 东西 需要 性 能 优化 工作 者 去 挖掘 ， 比 如 和 客户 进行 沟通 ， 也 许 
你 会 郁闷 地 发 现 ， 和 你 沟通 的 客户 根本 就 无 法 说 明白 为 什么 慢 ， 以 及 慢 在 哪里 。 


1.3 ”吞吐 量 和 响应 时 间 


吞吐 量 和 响应 时 间 是 衡量 Oracle 业 务 系统 的 基本 指标 ， 也 是 业务 系统 性 能 的 终极 指标 。 如 何 选择 恰当 的 指标 单元 来 描述 吞吐 量 和 响应 时 间 ， 并 
且 熟 练 运用 吞吐 量 和 响应 时 间 之 间 的 关系 是 性 能 优化 工作 者 最 为 重要 的 学 习 和 实践 。 吞 吐 量 和 响应 时 间 的 关系 曲线 如 此 重要 ， 以 至 于 本 书 几 乎 所 有 
的 章节 都 是 为 了 帮助 大 家 更 好 地 选择 恰当 的 吞吐 量 指标 ， 以 及 更 好 地 理解 吞吐 量 和 响应 时 间 的 关系 曲线 。Oracle 虽 然 从 Oracle 10gR1 就 开始 提供 
Time Based Analyze (TBA) 性 能 优化 分 析 方 法 论 ， 但 显然 其 并 未 认识 到 吞吐 量 和 响应 时 间 曲 线 的 重要 性 ， 甚 至 到 现在 依然 没有 明确 指出 该 曲线 
对 性 能 优化 具有 的 根本 性 理论 指导 作用 ， 这 也 致使 TBA 分 析 方 法 论 一 直 没 有 得 到 很 好 的 利用 。 


1.4 _ Oracle 性 能 优化 工作 的 分 类 


在 Oracle 上 进行 性 能 优化 时 ， 不 同 场景 下 的 优化 工作 方法 和 内 容 有 很 大 的 不 同 。 下 面 从 实践 角度 来 展开 优化 工作 的 分 类 。 


1.5 测量 和 变化 


1.5.1 测量 和 性 能 


没有 测量 就 没有 性 能 ， 任 何 科学 都 建立 在 可 测量 的 基础 之 上 。Oracle 数 据 库 和 基于 它 的 性 能 优化 理所当然 是 一 门 科 学 ， 而 不 是 一 门 艺术 。 科 学 
的 性 能 优化 首先 必须 是 可 以 建立 测量 的 目标 系统 性 能 指标 。 一 个 无 法 测量 的 系统 或 者 一 个 只 能 依赖 于 人 的 眼睛 、 耳 采 等 器 官 来 进行 感知 的 系统 是 无 
法 进行 性 能 优化 的 。 为 了 完成 性 能 优化 ， 需 要 做 大 量 的 可 测量 性 工作 。 幸 运 的 是 ，Oracle 对 于 可 测量 的 性 能 付出 了 巨大 的 努力 ， 使 其 性 能 相关 的 测 
量 指标 远 远 超出 了 其 他 数据 库 。 


从 性 能 优化 的 角度 出 发 ， 可 以 从 以 下 几 方 面 来 建立 性 能 优化 测量 指标 体系 。 

DUE: 指 从 发 命令 给 数据 库 ， 到 数据 库 返 回 我 们 需要 的 结果 的 整个 业务 处 理 流程 。 
' 资源 : 指 在 业务 处 理 流程 过 程 中 需要 使 用 的 软 硬 件 资源 ， 比 如 CPU、 内 存 等 。 

: 组 件 : 在 流程 处 理 中 涉及 的 处 理 单元 ， 比 如 buffer cache 等 。 


流程 是 业务 用 户 可 直接 感受 的 性 能 指标 ， 与 人 的 感官 感觉 紧密 相连 ， 性 能 优化 的 根本 目标 就 是 使 业务 流程 顺利 运转 。 构 建 性 能 优化 可 测量 体系 
的 一 个 简便 方法 是 从 项 层 目标 出 发 ， 进 行 分 解 和 推导 ， 发 现 其 测量 因子 之 间 的 依赖 性 、 相 关 性 和 影响 性 。 在 构建 此 体系 的 过 程 中 ， 若 把 Oracle 数 据 
库 及 业务 流程 中 涉及 的 所 有 组 件 和 资源 都 作为 一 个 设备 或 服务 来 看 ， 则 会 有 相当 的 便利 ， 更 具有 真实 性 。 


在 业务 流程 中 ， 当 把 资源 和 组 件 统一 作为 一 个 服务 中 心 看 待 时 ， 也 可 由 此 构造 出 统一 的 可 测量 指标 体系 ， 如 下 : 
“ 输入 型 指标 ; 
E 输出 型 指标 ; 
“ 状态 型 指标 。 


通过 上 述 测量 指标 一 起 作用 构建 出 Oracle 数 据 库 的 监控 体系 后 ， 即 可 检测 Oracle 业 务 流程 是 否 正常 运转 。 除 此 之 外 ， 为 了 更 快 地 完成 性 能 优 


化 ， 还 应 该 力求 在 可 测量 指标 之 间 建 立 关 联 ， 比 如 依赖 性 指标 、 相 关 性 指标 、 影 响 性 指标 等 。 这 样 就 可 以 通过 指标 相关 性 驱动 最 终 发 现 真正 导致 性 
能 变化 的 指标 ， 并 且 采 取 措 施 纠正 它 。 


再 次 查看 吞吐 量 和 响应 时 间 的 关系 曲线 ， 明 显 可 以 看 到 ， 响 应 时 间 是 流程 的 输出 结果 ， 而 吞吐 量 则 是 流程 的 输入 元 素 。 
下 面 来 看 一 个 简单 的 概念 性 示例 。 

假设 系统 业务 为 TPCC 测 试 的 订单 业务 ， 采 用 订单 数量 作为 吞吐 量 输入 指标 。 

吞吐 量 〈 输 入 型 指标 ) = 每 分 钟 完成 的 订单 数 。 

吞吐 量 (输入 型 指标 ) = (60/ 每 个 订单 的 响应 时 间 ) X 并行 处 理会 话 


这 里 并 不 是 在 念 绕口令 ， 


同一 个 指标 采用 不 同 的 计算 方式 在 性 能 优化 分 析 中 具有 重大 意义 ， 它 可 以 让 你 清晰 地 了 解 指标 之 间 的 关系 ， 从 而 采取 
正确 的 优化 方式 。 


根据 上 面 变种 的 吞吐 量 公式 ， 可 以 认为 以 下 两 个 结论 是 正确 的 。 


: 在 并 行 处 理会 话 确定 的 前 提 下 ， 降 低 每 个 订单 的 响应 时 间 可 以 提高 吞吐 量 。 


“ 在 每 个 订单 的 响应 时 间 确 定 的 情况 下 ， 增 加 并 行 处 理会 话 可 以 提高 吞吐 量 。 

有 足够 经 验 的 DBA 都 知道 ， 上 面 的 结论 完全 是 理论 推导 。 在 实际 的 环境 中 ， 若 遇 到 香 吐 量 下 降 的 场景 ， 且 每 个 订单 的 响应 时 间 延 长 ， 那 么 总 是 
可 以 观察 到 并 行 会 话 的 数量 增加 。 甚 至 可 以 认为 ， 在 业务 量变 化 不 大 的 前 提 下 ， 并 行 会 话 的 增加 必然 意味 着 吞吐 量 的 下 降 ， 而 这 正 是 订单 的 响应 时 
间 的 延长 导致 并 行 处 理会 话 增加 而 引起 的 。 


在 业务 变化 不 大 的 前 提 下 ， 从 以 上 分 析 可 以 得 出 如 下 结论 


E 


zy 


单 的 响应 时 间 延 长 会 导致 乔 吐 量 下 降 。 


. 


zy 


单 的 响应 时 间 延 长 会 导致 并 行 处 理会 话 增加 。 


' 并 行 处 理会 话 的 增加 和 吞吐 量 降 低 具 有 相关 关系 。 


为 什么 要 这 样 来 描述 ? 原因 很 简单 ， 因 为 每 个 订单 的 响应 时 间 是 相对 难以 测量 的 指标 ， 而 并 行 处 理会 话 极其 容易 被 测量 。 


订单 的 响应 时 间 = 订 单 的 处 理 时 间 + 订 单 的 等 待 时 间 
对 于 订单 的 处 理 时 间 和 订单 的 等 待 时 间 ，Oracle 都 在 系统 级 别 做 出 了 很 好 的 测量 。 


假设 图 1-8 所 示 的 曲线 图 中 那 两 个 圆 点 是 响应 时 间 和 吞吐 量 的 最 佳 平 衡 点 ， 且 在 这 个 平衡 点 上 有 服务 时 间 和 排队 时 间 ， 当 具体 的 订单 运行 点 落 
到 平衡 点 的 右边 或 者 上 边 的 时 候 就 意味 着 出 现 了 性 能 问题 。 每 次 订单 处 理 都 由 一 系列 的 众多 过 程 组 成 ， 每 次 订单 的 处 理 时 间 和 排队 时 间 自 然 也 由 一 
系列 众多 过 程 的 处 理 之 和 构成 ， 可 以 用 以 下 公式 来 表达 : 


订单 的 处 理 时 间 = 处 理 次 数 1X 每 次 处 理 时 间 1+ 处 理 次 数 2X 每 次 处 理 时 间 2+…… 


订单 的 排队 时 间 = 排 队 次 数 1X 每 次 排队 时 间 1+ 排 队 次 数 2X 每 次 排队 时 间 2+…… 


Oza 当 处 理 次数 发 生 明显 变化 时 ， 意 味 着 业务 特征 或 访问 特征 发 生 了 变化 。 对 于 任何 性 能 优化 DBA 来 说 ， 这 都 是 一 个 与 性 能 相关 的 直接 
要 素 。 而 对 于 每 次 处 理 时 间 ， 从 Oracle 数 据 库 的 描述 中 可 以 看 到 ， 服 务 处 理 是 由 CPU 来 执行 的 ， 正 常情 况 下 应 该 保持 稳定 ， 一 旦 其 发 生 明显 变化 ， 


就 意味 着 CPU 无 法 提供 足够 的 能 力 。 


排队 次 数 同 处 理 次 数 一 样 代表 着 业务 特征 或 访问 特征 ， 排 队 时 间 则 表示 访问 能 力 。 应 该 说 ，Oracle 数 据 库 系统 的 性 能 优化 工作 者 是 极其 幸运 
的 ， 响 应 时 间 的 分 解 几 乎 都 可 以 直接 或 间接 通过 测量 获得 ， 这 就 使 得 Oracle 数 据 库 系统 成 为 一 个 优化 就 绪 的 数据 库 系 统 。Otacle 数 据 库 不 仅 具 有 大 量 
的 状态 型 指标 ， 还 具有 丰富 的 输入 和 输出 指标 。Otacle 数 据 库 不 仅 关系 自身 的 零 部 件 是 否 运行 正常 ， 而 且 关 心 业务 操作 和 流程 运行 是 否 正常 ， 也 正 
因为 如 此 ， 它 使 得 所 有 这 些 东西 都 可 以 被 直接 或 者 间接 测量 。 


在 笔者 看 来 ， 也 许 只 有 Oracle 数 据 库 才 是 性 能 优化 就 绪 的 数据 库 。 


1.6 ”基线 管理 


1.6.1 基准 点 和 基线 


人 们 在 谈论 Oracle 业 务 系统 的 性 能 时 通常 会 说 它 运行 得 快 或 慢 ， 但 大 家 都 知道 快 和 慢 没 有 一 个 绝对 的 标准 ， 所 有 的 快 或 慢 都 是 基于 比较 而 言 
的 。 比 如 我 们 在 操场 上 15s 跑 完 100m， 没有 人 会 觉得 你 跑 得 快 ， 因 为 大 家 都 有 一 个 比较 的 基准 ， 大 部 分 人 都 可 以 在 12~15s 跑 完 。 同 样 是 100m， 如 
果 你 是 上 楼 梯 ， 那 大 家 可 能 会 觉得 你 的 速度 太 惊人 了 。 所 以 ， 快 慢 好 坏 都 是 基于 比较 而 言 的， 没有 比较 就 没有 性 能 的 好 和 坏 。 因 此 ， 为 了 使 性 能 优 
化 工作 更 加 科学 ， 需 要 建立 量化 的 性 能 基准 点 ， 而 不 能 依赖 于 经 验 来 建立 ， 毕 竟 经 验 很 难 放 之 四 海 而 皆 准 ， 每 次 衡量 快 或 者 慢 的 时 候 都 可 以 与 这 个 
基准 点 进行 比较 ， 这 个 基准 点 即 为 基线 。 在 Oracle 数 据 库 中 ， 同 样 需 要 建立 基准 点 或 者 基线 ， 用 来 描述 Oracle 业 务 系统 在 某 个 特定 的 状态 下 ， 特 定 
的 输入 响应 和 输出 响应 以 及 相应 提供 服务 的 各 个 资源 和 组 件 状况 。 当 后 续 的 业务 运营 和 基线 产生 预料 之 外 的 偏离 时 ， 则 表示 业务 系统 发 生 了 变化 ， 
不 管 是 否 会 产生 业务 系统 性 能 问题 ， 都 需要 运 维 人 员 介 入 。 


业务 运行 的 状态 可 能 在 不 同 的 时 间 点 表现 出 完全 不 同 的 业务 特征 ， 在 不 同 的 业务 特征 之 间 进 行 比较 是 没有 任何 意义 的 。 这 时 应 该 建立 多 个 基准 
点 来 完整 地 描述 业务 系统 的 运行 特征 。 比 如 电信 计 费 系统 在 白天 和 晚上 、 月 底 和 月 初 都 会 表现 出 不 同 的 特征 ， 因 此 就 需要 对 不 同时 间 点 都 建立 相应 
的 基准 点 或 基线 。 


下 面 通过 一 个 简单 的 例子 来 说 明基 线 之 于 性 能 优化 的 重要 性 。 


某 业 务 系统 的 性 能 最 近 变 得 很 差 ， 需 要 进行 性 能 优化 。 性 能 优化 专家 发 现 一 个 明显 的 现象 一 CPU 利用 率 达 到 100%， 几 乎 没有 空闲 时 间 。 依 
据 经 验 ， 该 专家 认为 这 个 100% 的 CPU 利用 率 是 属于 一 个 坏 指标 ， 并 且 认为 这 是 其 根本 原因 。 通 过 艰苦 的 优化 工作 ，CPU 利 用 率 有 所 下 降 ， 但 是 | 
能 并 没有 提高 ， 可 以 想象 ， 应 该 是 专家 找 错 了 方向 。 事 实 上 ， 这 个 系统 自 上 线 以 来 其 CPU 一 直 工 作 在 100% 状 态 下 ， 且 运行 良好 。 在 这 种 情况 下， 
如 果 有 了 CPU 的 利用 率 基线 ， 专 家 就 不 会 犯 这 个 错误 ， 可 以 正确 地 把 握 方向 。 而 且 ， 如 果 进 一 步 测量 指标 可 以 发 现 ， 虽然 CPU 利 用 率 为 100%， 但 
是 其 服务 能 力 没有 任何 问题 ， 并 且 没 有 在 CPU 上 形成 大 规模 冲突 导致 其 单 次 服务 能 力 下 降 。 

基线 的 存在 可 以 大 大 减轻 性 能 优化 者 的 负担 ， 基 线 的 存在 可 以 使 性 能 优化 不 再 是 高 手 的 专利 ， 普 通 的 性 能 优化 工作 者 甚至 是 缺乏 任何 数据 库 知 
识 的 人 都 可 以 轻松 地 发 现 导 致 业务 系统 性 能 变 差 的 原因 : 只 要 把 每 个 可 测量 的 指标 值 和 该 指标 的 基线 值 进行 比较 ， 出 现 大 规模 偏差 的 一 般 就 是 性 能 
问题 的 根源 所 在 。 


1.7 ” Oracle 性 能 优化 的 神话 和 误区 


Oracle 性 能 优化 工作 是 Oracle 数 据 库 科 学 最 为 神秘 莫 测 的 领域 ， 自 然 也 就 会 流传 着 各 种 传言 和 八卦 。 本 书 最 主要 的 目的 就 是 真正 使 Oracle 性 能 
优化 成 为 一 门 严谨 的 科学 ， 使 任何 阅读 并 且 理 解 本 书 内 容 的 读者 可 以 比较 简单 地 完成 Oracle 性 能 优化 工作 ， 使 自己 在 其 他 人 面前 成 为 “还 
师 ” 或 “神秘 的 对 象 ”。 


982: “Oracle 性 能 优化 方法 论 的 发 展 


Oracle 数 据 库 在 开发 和 使 用 过 程 中 对 数据 库 的 性 能 优化 极为 重视 ， 几 乎 在 每 个 版 本 的 更 新 中 都 会 对 可 优化 的 数据 库 做 出 改善 。 不 仅 如 
此 ，Oracle 数 据 库 还 会 使 用 优化 方法 来 指导 性 能 优化 ， 会 不 断 推 出 新 的 性 能 优化 方法 论 ， 并 依据 优化 方法 论 持 续 完 善 其 可 观察 的 性 能 优化 体系 。 


从 Oracle 6 到 现在 的 Oracle 12c， 经 历 了 Oracle 7. Oracle 8, Oracle 8i, Oracle 9i & R2, Oracle 10gR1 & R2, Oracle 11gR1 & R2 和 
Oracle 12c 等 版 本 的 更 新 。 从 Oracle 7 开始 商定 Oracle 的 江湖 地 位 ，Oracle 8 开始 超越 ， 到 Oracle 8i 的 大 红 大 紫 ， 以 及 Oracle 9i 以 来 的 持续 保持 
和 发 展 ， 每 个 版 本 都 有 其 特色 和 定位 。 在 Oracle 的 主要 发 展 版 本 中 可 以 看 到 Oracle 性 能 优化 方法 论 的 持续 发 展 。Oracle 7 中 成 熟 的 命中 率 分 析 方 
法 ，Oracle 8 开始 出 现 OWI (Oracle Wait Interface) 的 影子 ， 到 Oracle 8i，OWI 开 始 走 向 前 台 并 快速 成 熟 起 来 。 由 于 OW/I 方 法 的 简单 实用 ， 目 
前 它 是 Oracle 性 能 优化 方法 论 中 的 主流 。Oracle 8i 能 大 红 大 紫 应 该 有 OW/I 方 法 的 贡献 。 从 Oracle 8i 开 始 ，Oracle 的 性 能 优化 方法 论 远 远 超过 了 其 
他 同类 的 数据 库 ，Oracle 真 正成 为 性 能 优化 就 绪 的 数据 库 。Oracle 9i 开 始 出 现 TBA (Time Based Analyze) 和 基线 管理 ， 并 在 Oracle 10g 版 本 中 


发 现 平均 化 可 能 面临 的 问题 。 


Oracle 11gR2 中 的 TBA 性 能 分 析 方 法 论 还 不 太 成 熟 ， 但 是 TBA 方 法 已 经 在 一 些 复杂 的 性 能 优化 案例 中 体现 出 了 威力 。 除 TBA 之 外 ，Craig 
Shallahameril] 提 出 了 UOWTBA (Unit of Work Time Based Analyze) 方法 论 ， 笔 者 认为 UOWTBA 是 TBA 方 法 的 重大 改善 ， 可 使 TBA 方 法 被 真 
正 有 效 地 使 用 。 本 书 将 以 UOWTBA 方 法 为 基础 ， 提 出 了 基于 流程 、 资 源 和 组 件 的 综合 性 能 优化 方法 论 ， 构 建 了 全 新 的 Oracle 数 据 库 性 能 优化 的 可 
测量 体系 。 


[1] Craig Shallahamer: 著名 Otracle 性 能 专家 和 咨询 顾问 ，OraPub 的 创始 人 。 


2.1 基于 局 部 命中 率 分 析 的 优化 方法 论 


案例 描述 : 某 市 工商 局 的 综合 业务 处 理 系统 报告 长 期 以 来 在 业务 忙碌 的 时 候 运 行 缓慢 。 笔 者 指导 客户 生成 AWR 报 告 ， 发 现 Cache Hit Ratio 只 
137296, Top 5wait 主 要 为 db file sequence read 和 db file scattered read。 检 查 SGA buffer cache 配 置 ， 只 有 375MB。 简 单 增 加 buffer cache 
到 2GB， 所 有 性 能 问题 都 消失 。 


在 目前 ， 一 个 性 能 优化 工作 者 遇 到 上 述 案例 的 性 能 优化 需求 ， 与 中 彩票 类 似 ， 一 般 只 有 在 菜鸟 安装 的 数据 库 中 才 会 存在。 
基于 命中 率 的 分 析 方法 是 一 个 古老 的 性 能 优化 方法 论 ， 不 仅 是 在 Oracle 数 据 库 中 ， 在 Sybase、DB2 等 数据 库 ， 甚 至 在 任何 IT 设备 中 都 存在 基于 


命中 率 的 分 析 方 法 。 对 于 Oracle 数 据 库 而 言 ， 局 部 命中 率 的 分 析 方法 基于 以 下 朴素 的 观点 : 如 果 构 成 系统 的 每 个 零件 都 表现 优异 ， 那 么 整个 系统 的 
表现 也 是 优异 的 。 当 然 ， 任 何 具有 流程 知识 的 人 员 都 知道 以 上 观点 是 不 可 靠 的 。 


如 图 2-1 所 示 ， 以 我 们 的 经 验 来 看 ， 其 中 B 路 段 会 成 为 高 吞吐 量 场景 中 的 瓶颈 ， 会 导致 整 条 马路 的 车 流 不 畅 ( 那 是 因为 有 全 局 观点 了 ) 。 但 是 ， 
如 果 站 在 B 路 段 内 部 来 看 问题 ， 即 使 在 业务 最 高 峰 的 时 候 ，B 路 段 也 表现 出 运行 非常 流畅 ， 吞 吐 量 表现 极 好 ， 也 许 会 成 为 表现 最 好 的 路 段 (如 臭名 昭 
著 的 新 岭 隧道 ， 有 兴趣 的 读者 可 以 上 网 搜索 一 下 ) 。 基 于 命中 率 的 分 析 方 法 与 B 路 段 的 观察 者 和 管理 者 一 样 ， 它 只 关心 内 部 的 表现 或 者 自己 的 表 
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图 2-1 车辆 穿 过 A 路 段 、B 路 段 和 C 路 段 


命中 率 的 分 析 方 法 作用 于 性 能 优化 ， 具 有 以 下 致命 的 缺陷 。 
* 命中 率 分 析 仅 关注 和 作用 于 自身 ， 不 关心 外 部 信息 。 


这 里 以 马路 收费 站 作为 例子 ， 命 中 率 分 析 方 法 仅 关 心 通过 收费 站 的 吞吐 量 是 否 正 常 ， 而 看 不 到 等 待 穿 过 收费 站 的 长 长 的 队伍 。 从 命中 率 的 观点 
出 发 ， 只 要 收费 站 操作 顺利 ， 不 出 现 故障 ， 即 使 队伍 排 成 10km 的 长 龙 也 是 性 能 优异 的 。 


“ 命中 率 分 析 方 法 通过 全 局 平均 化 模糊 了 个 体 ， 而 大 部 分 性 能 问题 都 是 基于 个 体 的 。 


比如 某 个 心 外 科 手 术 医 生 对 于 心脏 搭桥 手术 的 成 功率 为 98%， 每 年 做 500 例 手术 ， 但 是 对 于 那 10 个 落 在 2% 的 病人 来 说 成 功率 就 不 是 98%， 而 是 
100% 丢 了 性 命 。 


尽管 命中 率 分 析 方 法 明显 不 可 靠 , 但 由 于 其 获取 数据 的 成 本 低廉 以 及 易于 理解 ， 也 具备 描述 目标 基本 性 能 的 能 力 ， 事 实 上 ， 它 已 成 为 IT 设 备 甚 
至 生活 中 工作 性 能 的 标准 描述 方法 。 对 于 命中 率 分 析 方 法 ,我们 可 以 这 样 来 描述 它 : 命中 率 分 析 结果 优秀 ， 不 能 保证 业务 系统 或 者 数据 库 具 有 优异 
的 性 能 ; 命中 率 分 析 结 果 不 好 ， 基 本 可 以 确认 业务 系统 或 者 数据 库 不 具备 优异 的 性 能 。 在 Oracle 性 能 优化 中 ， 命 中 率 分 析 方 法 不 足以 成 为 独立 工作 
的 方法 论 ， 但 必须 成 为 辅助 分 析 的 一 部 分 ， 只 有 确保 Oracle 每 一 个 部 件 自身 的 工作 表现 优异 才 可 以 使 业务 性 能 表现 优异 ，Oracle 的 某 个 部 件 工作 表 
现 不 正常 ， 几 乎 可 以 断定 业务 性 能 不 会 反应 良好 。 事 实 上 ， 我 们 只 要 把 视野 抬 高 一 十， 把 自身 部 件 和 设备 作为 全 局 流程 处 理 过程 中 的 一 个 节点 ， 自 
然 就 会 把 输入 和 输出 作为 衡量 自身 部 件 和 设备 的 重要 衡量 因素 ， 从 而 使 古老 的 命中 率 分 析 方 法 依然 在 最 新 的 性 能 优化 时 代 发 挥 出 其 固有 的 作用 。 


命中 率 可 以 体现 在 不 同 的 颗粒 度 上 ， 如 系统 全 局 层 、 会 话 层 、 对 象 层 和 SQL 层 等 。 下 面 以 buffer cache 命 中 率 来 说 明 命中 率 分 析 的 不 同 层次 。 
计算 公式 : buffer cache hit ratio=logical reads/ (logical reads+physical reads) 

系统 全 局 层 : v$sysstat 或 者 V$BUFFER POOL STATISTICS 

会 话 层 : v$sesstat 或 者 v$sessio 对 象 层 ; v$segstat 或 者 v$segment statistics 

SQL 层 : v$sqlarea 


具体 到 某 session 的 一 条 SQL 或 某 一 时 间 段 的 命中 率 ， 还 可 以 通过 SQL Trace 或 者 10046 跟 踪 得 到 ， 如 下 : 


all count cpu elapsed disk query current rows 
Parse 19 0.72 0,75 0 0 
OExecute 19 0.17 0.13 0 0 0 

OFetch 19 0.65 0.64 0 83049 12369 114 

total 57 1.54 1.52 0 83049 12369 114 


22 ”基于 OWI 的 优化 方法 论 


2.2.1 ”OWI 优化 方法 论 简 述 


OWI, 是 Oracle Wait Interface 的 简称 。 最 开始 OWI 并 不 是 为 了 性 能 优化 而 出 现 的 ， 而 是 出 于 调试 的 目的 ， 用 来 明确 当前 正在 发 生 什么 事 
情 ， 在 Oracle 7 中 它 就 已 经 以 初级 的 方式 存在 了 。 当 Oracle 8i 极 其 明确 地 把 OWI 引 入 性 能 优化 时 ， 数 据 库 性 能 优化 方法 论 就 出 现 了 划时代 的 飞跃 。 
OWI 方 法 论 让 Oracle 第 一 次 跳出 部 件 构成 性 能 的 视野 ， 从 一 个 旁观 者 的 角度 或 者 业务 流程 的 角度 来 考虑 问题 ， 使 其 与 现实 世界 的 基于 流程 协调 的 流 
程 优化 相符 合 。 


排队 和 冲突 是 现实 世界 中 时 时 刻 刻 普遍 发 生 的 事件 ， 我 们 吃饭 要 排队 、 购 物 要 排队 、 上 和 车 要 排队 、 看 病 要 排队 ， 甚 至 走路 都 要 排队 。 如 果 不 想 
被 前 面 的 人 或 者 物 堵 住 ， 需 要 不 断 地 变换 通道 或 者 将 障碍 进行 拆除 ， 我 们 的 观点 和 行为 会 不 断 地 发 生 冲突 。Oracle OW 方法论 充分 地 认识 到 了 排 
队 和 冲突 是 生活 的 主题 ， 是 数据 库 流程 的 主题 。 例 如 ， 特 别 典型 的 是 看 医生 ， 每 个 人 都 有 切身 体会 。 排 队 挂号 ， 排 队 看 医生 ， 排 队 检查 ， 排 队 拿 
药 ， 各 种 排队 合计 3 个 小 时 ， 医 生 看 病 处 理 不 超过 5 分 钟 。 只 要 可 以 降低 排队 时 间 ， 就 可 以 提高 效率 ， 降 低 时 间 成 本 。OWI 就 是 基于 这 个 朴素 的 理念 
的 ， 只 要 使 各 种 等 待 所 消耗 的 时 间 尽 可 能 低 ， 就 可 以 提高 业务 系统 的 性 能 。 对 于 Oracle 来 说 ，OWI 的 发 展 就 是 尽 可 能 精细 地 衡量 等 待 事件 ， 对 于 性 
能 优化 者 而 言 ， 就 是 发 现 等 待 事件 的 原因 并 且 尽 可 能 降低 或 者 消除 它 。 


OWI 方 法 是 快速 优化 Oracle 性 能 的 最 有 效 方式 ，OWI 的 精准 定位 使 性 能 优化 不 再 需要 到 处 进行 衡量 。 某 种 程度 上 ，OWI 方 法 论 类 似 于 故障 处 
理 的 思路 ， 处 理 焦点 在 局 部 ， 使 优化 者 无 需 了 解 业务 流程 ， 无 需 进行 全 局 流程 的 协调 ， 降 低 了 对 性 能 优化 者 的 能 力 要 求 。 


至 今 为 止 ，OW/I 方 法 依然 是 最 为 快速 有 效 的 性 能 优化 方法 。 昌 然 如 此 ， 由 于 OWI 关 注 的 局 限 性 ， 有 一 些 缺 陷 ， 使 其 解决 复杂 的 性 能 问题 时 有 些 
力不从心 ， 更 多 只 作用 在 突然 变化 的 性 能 异 变 上 。 
OW 方法 事实 上 并 不 是 从 业务 (流程 ) 的 角度 看 问题 ， 而 是 从 CPU 的 角度 看 问题 ， 只 要 CPU 一 直 处 于 忙碌 之 中 ， 就 假设 性 能 是 优异 的 。 这 就 忽 


略 了 在 很 多 场合 下 CPU 的 处 理 效率 才 是 性 能 问题 的 本 源 所 在 。OWI 方 法 从 本 质 上 与 基于 局 部 命中 率 分 析 方 法 类 似 ， 都 是 眼睛 向 内 看 。 一 个 是 只 要 我 
忙 ， 系 统 就 好 ; 一 个 是 只 要 我 好 ， 系 统 就 好 ， 总 体 来 说 都 缺乏 流程 的 概念 。OWI 的 使 用 如 此 简单 ， 效 果 是 如 此 出 色 ， 使 绝 大 部 分 性 能 优化 者 不 再 去 


关心 流程 ， 而 仅 关心 发 生性 能 问题 的 某 一 点 。OW/I 方 法 在 快速 优化 性 能 的 同时 ， 事 实 上 割裂 了 业务 流程 之 间 的 关系 ， 往 往 使 复杂 的 性 能 优化 工作 顾 
此 失 彼 。 


OWI 优 化 工作 者 总 是 精心 研究 常见 的 Oracle 等 待 事件 ， 研 究 其 等 待 事件 可 能 发 生 的 原因 以 及 对 应 的 解决 方案 。OWI 优 化 方法 获得 各 个 级 别 
DBA 的 厚爱 ， 除 了 其 简单 有 效 之 外 ， 最 为 重要 的 原因 在 于 其 可 以 不 用 过 多 考虑 业务 相关 问题 ， 只 用 采用 故障 解决 的 思维 逻辑 来 解决 性 能 优化 问题 。 


2.3 ”响应 时 间 分 析 优 化 方法 论 


2.3.1 RTA ACA 


响应 时 间 分 析 (Response Time Analyze, RTA) 的 性 能 优化 方法 论 是 基于 OWI 的 性 能 优化 方法 论 发 展 起 来 的 ， 标 志 着 Oracle 开 始 认识 到 
Oracle 性 能 优化 其 实 就 是 一 个 流程 改善 的 过 程 (减少 响应 时 间 ) ， 首 次 在 性 能 优化 上 跳出 了 IT 设备 的 观点 ， 从 业务 流程 优化 的 角度 来 考虑 问题 。 在 
任何 场合 下 ， 流 程 改善 或 者 性 能 优化 最 为 适当 的 方法 就 是 RTA。 


Oracle 从 9.2 版 本 开始 提供 RTA， 在 Oracle 10g 中 进行 了 进一步 的 完善 。RTA 优 化 方法 论 可 以 采用 下 面 的 简单 公式 来 描述 : 
响应 时 间 (Rt) = 服务 时 间 (Ts) + 等 待 时 间 (Tw) 

Rt=Response time 

=Ts+Tw=Time for Setvice Time for Wait 

=St+Wt=Setvice Time+ Wait Time 

=St+Qt=Service Time Queue Time 

‘Ts=Service Time 


=CPU Time 


—Oracle Kernel code execution time 

'Tw-Wait Time 

—Queue Time 

—Oracle Wait event time 

—iowaitt Networkwait--concurrencywait- otherwait 


RTA 是 流程 改善 (性 能 优化 ) 的 最 佳 利器 。 流 程 最 基本 的 单元 是 SQL， 其 次 是 事务 。 我 们 可 以 进一步 把 统计 上 升 到 session 和 全 局 。Oracle 9i 
仅 实 现 了 基于 session 和 系统 全 局 的 RTA， 还 没有 完整 的 流程 概念 。Oracle 10g 完 全 确定 了 时 间 分 析 模 型 ， 特 别 是 Oracle 10g 引 进 了 接近 实时 的 业 
务 流程 跟踪 (v$active session history) ， 可 以 很 好 地 完成 RTA。 


Oracle 119R2 中 RTA 可 检测 体系 的 构成 如 下 。 


System Level: v$sys time model 
Session Level:  v$sess time model 
SQL Level: v$sqlstat,v$sql monitor 


Realtime Level: v$active session history 
Snapshot Level: dba hist sess history 
Minter Level: v$metric,v$metric history 


Oracle 在 v$sys time_model 和 v$sess time_model 中 给 出 了 以 下 不 同 阶段 和 操作 的 响应 时 间 指 标 : 
: DB time; 

: DB CPU; 

* background elapsed time; 

* background cpu time; 

- sequence load elapsed time; 

- parse time elapsed; 

* hard parse elapsed time; 

* sql execute elapsed time ; 

< connection management call elapsed time; 

- failed parse elapsed time ; 

- failed parse (out of shared memory) elapsed time; 
- hard parse. (sharing criteria) elapsed time; 

* hard parse. (bind mismatch) elapsed time; 

: PL/SQL execution elapsed time; 

- inbound PL/SQL rpc elapsed time; 

: PL/SQL compilation elapsed time; 

: Java execution elapsed time; 

- repeated bind elapsed time; 


- RMAN cpu time (backup/restore) o 


Oracle 在 v$sqlstat 中 标记 了 关于 SQL 语句 的 响应 时 间 指 标 : 
- CPU. TIME; 
- ELAPSED TIME; 
- AVG. HARD. PARSE, TIME; 
- APPLICATION. WAIT. TIME ; 
- CONCURRENCY. WAIT. TIME; 
- CLUSTER. WAIT. TIME; 
- USER. IO, WAIT. TIME; 
- PLSQL EXEC. TIME; 
- JAVA, EXEC, TIME, 


Oracle 在 v$active_session_history 中 实现 了 基于 近 实 时 的 流程 流逝 过 程 ， 特 别 是 在 11g9R2 版 本 中 已 经 完全 实现 基于 session 的 逐条 SQL 的 时 间 
流逝 。 下 面 是 v$active_session_history 关 于 SQL 实时 执行 的 相关 信息 : 


- SQL ID; 


- WAIT. TIME; 


: SESSION STATE; 


: SQL EXEC ID; 


- SQL EXEC, START; 


- Time Model; 


: IN CONNECTION MGMT; 


- IN. PARSE; 


: IN HARD PARSE; 


: IN. SQL EXECUTION; 


: IN PLSQL EXECUTION; 


: IN PLSQL RPC; 


: IN PLSQL COMPILATION; 


: IN JAVA. EXECUTION; 


- IN. BIND; 


: IN. CURSOR, CLOSE; 


: IN SEQUENCE LOAD; 


: TM DELTA. TIME; 


: TM DELTA CPU TIME; 


: TM. DELTA DB TIME, 


在 视图 v$metric 中 Oracle 实 现 了 大 量 的 响应 时 间 统 计 指标 。 


24 ”基于 工作 单元 的 响应 时 间 分 析 优 化 方法 论 


24.1 UOWTBA 优 化 方法 论 的 导入 


在 RTA 工 作 方 法 论 的 基础 上 ，Craig Shallahamer 结 合 吞吐 量 和 响应 时 间 关系 曲线 图 提出 了 基于 工作 单元 的 响应 时 间 分 析 方 法 论 (Unit of 
Work Time Based Analyze，UOWTBA 或 者 Unit of Response Time Analyze，UOWRTA) 。UOWTBA 方 法 论 相 较 于 RTA 方 法 论 而 言 ， 在 强调 响 
应 时 间 时 ， 同 等 强调 了 吞吐 量 的 重要 性 ， 它 通过 衡量 操作 单元 的 响应 时 间 而 不 是 绝对 时 间 来 完成 性 能 优化 。 


工作 单元 的 最 简单 说 法 就 是 某 个 特定 操作 粒度 之 上 的 操作 ， 比 如 一 次 逻辑 读 、 一 次 物理 读 、 一 次 latch gets、 一 次 mutex gets、 一 次 parse 
call 等 。 工 作 单 元 的 粒度 根据 需要 分 析 的 场景 而 定 ， 相 对 来 说 ， 由 于 工作 单元 的 时 间 响 应 需要 作为 顶层 业务 作业 的 可 比较 单元 ， 所 以 需要 选择 相对 
基础 的 细 粒 度 工作 。 

再 次 来 看 吞吐 量 和 响应 时 间 关 系 曲线 。 


吞吐 量 和 响应 时 间 关 系 曲线 极为 明确 地 揭示 了 一 个 本 质 现象 : 任何 输出 响应 时 间 都 是 在 特定 的 输入 吞吐 量 下 才 会 表现 出 其 业务 价值 的 。 
UOWTBA 优 化 方法 论 强调 了 输入 吞吐 量 单元 ， 其 响应 时 间 总 是 标记 为 单个 输入 吞吐 量 单元 的 响应 时 间 。 


性 能 优化 的 目标 就 是 延长 曲线 突变 点 ， 从 而 使 其 可 以 获得 更 高 的 吞吐 量 。TBA 关 键 的 问题 在 于 缺乏 衡量 吞吐 量 的 基础 标准 ， 或 者 对 于 每 个 业务 
系统 都 具有 其 特定 吞吐 量 描述 ， 这 样 就 给 TBA 分 析 带 来 巨大 的 困难 。 比 如 CRM 业 务 系统 ， 其 标准 吞吐 量 为: 每 小 时 5000 个 受理 、20000 个 开通 等 描 
述 ， 但 会 发 现 你 无 法 把 这 些 描述 和 数据 库 的 监控 关联 起 来 。 


Oracle 数 据 库 有 很 多 标记 吞吐 量 的 指标 变量 ， 比 如 executes、user calls、transactions 等 ， 事 实 上 ，Oracle 11gR2 的 RTA 方 法 论 中 也 涉及 了 
衡量 基于 executes、user calls、transactions 等 输入 吞吐 量 的 输出 响应 时 间 。 大 家 可 以 很 明显 地 看 到 ， 虽 然 从 业务 输入 层面 上 transactions、 
executes 都 是 可 以 感知 的 输入 吞吐 量 的 ， 但 是 execute 和 execute、transactions 和 transaction 之 间 的 个 体 差异 太 大 ， 使 其 输入 吞吐 量 缺 乏 一 致 性 
比较 的 基础 。 比 如 执行 10 万 次 的 SQL 语句 “select*from dual” 自 然 无 法 和 执行 10 万 次 的 SQL 语句 “select*from dba_objects” 相 比较 。 
transactions 也 是 同样 的 道理 ， 除 了 一 些 业务 极为 均匀 的 系统 外 ， 无 法 作为 吞吐 量 输入 衡量 的 基础 。 


为 了 获得 一 个 通用 的 业务 特征 和 吞吐 量 的 描述 ， 笔 者 在 TBA 的 基础 之 上 进行 了 进一步 的 研究 ， 希 望 获得 更 好 的 描述 访问 特征 和 访问 能 力 的 监控 
由 标 ， 以 更 有 效 地 完成 TBA 分 析 。Craig A.Shallahamer 的 研究 成 果 正好 和 我 所 寻求 的 方向 一 致 ， 基 于 工作 单元 的 TBA 分 析 方 法 可 以 很 好 地 弥补 TBA 
方法 的 不 足 。Craig A.Shallahamer 的 具体 成 果 可 以 参考 他 的 网 站 : http://www.orapub.com。 


25 ”基于 资源 瓶颈 分 析 的 优化 方法 论 


2.5.1 ”基于 资源 瓶颈 分 析 优 化 方法 论 简 述 


Oracle 要 做 优化 ， 大 部 分 人 首先 会 想到 瓶颈 在 哪里 ? 资源 瓶颈 分 析 是 如 此 之 普及 ， 以 至 于 无 论 懂 还 是 不 懂 的 人 都 知道 “ 尊 颈 ”这 个 术语 ， 都 知 
道 性 能 优化 首先 要 找到 这 个 瓶颈 ， 然 后 消除 这 个 瓶颈 。 数 据 库 系统 的 资源 主要 包括 : CPU、 内 存 和 虚拟 内 存 、I/O 子 系统 、 网 络 子 系统 。 


绝 大 部 分 开发 人 员 在 写 程序 的 时 候 都 假设 资源 是 无 限 的 ，CPU 是 无 限 快 ， 内 存 是 无 限 多 ， 磁 盘 无 限 大 并 且 像 内 存 一 样 快 ， 网 络 带宽 无 限 并 且 像 
光速 一 样 运行 。 事 实 上 ， 大 家 都 知道 ，Oracle 数 据 库 总 是 在 资源 有 限 的 环境 下 运行 ， 我 们 总 是 在 资源 有 限 的 环境 下 生存 和 发 展 。 瓶 颈 分 析 就 是 建立 
在 资源 有 限 的 运行 环境 下 ， 通 过 发 现 瓶 颈 和 消除 瓶颈 的 过 程 来 改善 数据 库 或 者 业务 系统 性 能 。 


只 要 数据 库 系统 的 资源 足够 ， 业 务 系统 一 定 会 良好 运行 ， 这 是 资源 瓶颈 分 析 优 化 理论 的 信条 。 每 个 有 一 定 经 验 的 DBA 都 知道 ， 真 正 考验 Oracle 
数据 库 知 吐 量 的 是 其 并 发 处 理 能 力 ， 而 不 是 资源 供给 能 力 ， 充 分 的 资源 并 不 能 完全 保障 业务 系统 的 快速 运行 。Oracle 从 本 质 上 是 一 个 巨大 的 串 行 同 


步 系 统 ， 需 要 大 量 的 lock、latch 和 mutex 的 支持 才 可 以 实现 互 不 干扰 的 访问 ， 充 分 的 资源 有 助 于 Oracle 快 速 通过 串 行 通道 ， 但 无 法 保证 在 串 行 通 
道 发 生 的 冲突 。 


基于 资源 瓶颈 分 析 的 优化 方法 论 具有 以 下 局 限 性 。 
- 充分 的 资源 并 不 能 保证 业务 系统 具备 高 性 能 。 
: 资源 之 间 的 瓶颈 会 相互 转化 ，CPU 瓶 颈 的 消失 会 导致 输入 、 输 出 瓶颈 ， 内 存 瓶 颈 的 消失 会 导致 CPU 瓶颈 。 
: 资源 利用 率 过 高 是 性 能 不 佳 的 滞后 性 指标 表现 ， 它 只 是 其 他 藏 在 后 面 的 真实 原因 的 最 后 表现 。 
我 们 可 以 用 下 面 几 个 简单 的 描述 性 场景 来 描述 资源 瓶颈 分 析 优 化 方法 论 的 局 限 性 。 
简单 场景 描述 一 : 一 个 大 量 行 锁 冲 突 的 系统 ， 可 以 发 现 冲突 严重 时 CPU 和 I/O 会 极度 空闲 ， 而 这 时 业务 会 几乎 挂 起 。 


简单 场景 描述 二 : 一 个 高 吞吐 量 事务 提交 的 系统 ， 可 以 发 现 整体 MO 资源 空 亲 ， 某 块 磁盘 1/O 特 别 紧 张 ， 你 会 发 现 无 法 利用 大 量 空闲 的 MO 资 


简单 场景 描述 三 : 一 个 资源 极为 空闲 的 系统 ， 系 统 吞吐 量 不 佳 ， 而 且 无 法 增加 资源 利用 率 以 提高 系统 吞吐 量 。 


简单 场景 描述 四 : 一 个 资源 空闲 的 系统 ， 响 应 时 间 总 是 无 法 满足 。 


2.6 流程、 资源 和 组 件 优 化 方法 论 


流程 、 资 源 和 组 件 优化 方法 论 是 本 书 几 位 作者 综合 多 年 性 能 优化 方法 论 实践 提出 的 最 新 的 Oracle 业 务 系统 性 能 优化 方法 论 。 流 程 、 资 源 和 组 件 
优化 方法 论 以 流程 响应 分 析 为 核心 ， 辅 助 以 流程 处 理 的 组 件 和 涉及 的 资源 分 析 ， 发 现 导致 性 能 问题 的 根本 原因 ， 并 采取 适当 的 手段 进行 性 能 改善 。 
本 书 从 流程 、 资 源 和 组 件 优 化 方法 论 出 故 ， 全 面 构 建 性 能 优化 的 可 测量 体系 ， 并 通过 大 量 的 性 能 优化 实践 案例 来 验证 方法 论 的 有 效 性 。 
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3.1 “数据库 登录 导致 业务 系统 性 能 恶化 案例 分 享 


某 运营 商 发 现 ， 从 早上 就 开始 接 到 大 量 的 营 账 业务 系统 性 能 恶化 的 投诉 ， 主 要 集中 在 通过 账 务 系统 访问 CRM 系 统 的 业务 处 理 中 。 手 动 发 起 连 
接 到 CRM 系 统 的 登录 响应 速度 也 非常 慢 ， 从 CRM 系 统 的 listener.log 以 及 session 跟 踪 可 以 发 现 每 秒 有 100 多 个 listener 发 起 连接 ， 绝 大 部 分 来 自 于 
账户 系统 的 database link。 通 过 业务 变化 确认 ， 相 比 于 昨天 ， 今 天 的 业务 增加 了 关闭 database link 的 操作 ， 用 于 降低 CRM 系 统 的 session 数 量 。 


经 过 现场 确认 ， 在 数据 库 服 务 器 本 机 中 执行 的 tnsping 操 作 每 次 达到 1000ms 以 上 ， 而 且 数 据 库 的 listener CPU 占 用 率 比较 高 。 应 急 处 理 办 法 
为 : 通过 增加 listener 数 量 以 均衡 负载 ， 提 高 listener 的 总 处 理 能 力 ， 应 对 白天 的 业务 需求 。 在 业务 周期 结束 后 ， 我 们 对 CRM 系 统 的 listener 进 行 了 
人 工 模拟 的 数据 库 登录 并 发 压力 测试 ， 在 每 秒 并 发 数量 达到 100 以 上 之 后 ，tnsping 的 listener 响 应 时 间 迅 速 增加 到 1000ms 以 上 ， 验 证 了 listener 处 
理 能 力 不 足 。 经 过 权衡 ， 开 发 保留 了 频繁 交互 的 CRM 系 统 和 账户 之 间 的 database link 的 可 持续 会 话 ， 及 时 关闭 来 自 其 他 不 太 频 繁 的 database 
link。 

从 以 上 案例 描述 中 ， 我 们 发 现 以 下 几 点 。 


:listenet 的 并 发 处 理 能 力 是 有 限 的 ， 而 且 并 不 是 很 高 。 


“ 数据 库 登 录 的 整个 流程 即使 正常 运行 ， 所 需要 的 时 间 也 经 常 达 到 180ms 以 上 。 


- XH database link 使 得 database link 32: [9] 3E 9X 4k 32 I] 2035 3 EHE ACIE HR, om S AGE BEA SC ng JL E T8] 48 ANT. Me en 9. 68 Rp IS] je E o 
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3.1 数据库 登录 导致 业务 系统 性 能 恶化 案例 分 享 


某 运营 商 发 现 ， 从 早上 就 开始 接 到 大 量 的 营 账 业务 系统 性 能 恶化 的 投诉 ， 主 要 集中 在 通过 账 务 系统 访问 CRM 系 统 的 业务 处 理 中 。 手 动 发 起 连 
接 到 CRM 系 统 的 登录 响应 速度 也 非常 慢 ， 从 CRM 系 统 的 listener.log 以 及 session 跟 踪 可 以 发 现 每 秒 有 100 多 个 listener 发 起 连接 ， 绝 大 部 分 来 自 于 
账户 系统 的 database link。 通 过 业务 变化 确认 ， 相 比 于 昨天 ， 今 天 的 业务 增加 了 关闭 database link 的 操作 ， 用 于 降低 CRM 系 统 的 session 数 量 。 


经 过 现场 确认 ， 在 数据 库 服务 器 本 机 中 执行 的 tnsping 操 作 每 次 达到 1000ms 以 上 ， 而 且 数 据 库 的 listener CPU 占用 率 比 较 高 。 应 急 处 理 办 法 
为 : 通过 增加 listener 数 量 以 均衡 负载 ， 提 高 listener 的 总 处 理 能 力 ， 应 对 白天 的 业务 需求 。 在 业务 周期 结束 后 ， 我 们 对 CRM 系 统 的 listener 进 行 了 
人 工 模拟 的 数据 库 登 录 并 发 压力 测试 ， 在 每 秒 并 发 数量 达到 100 以 上 之 后 ，tnsping 的 listener 响 应 时 间 迅 速 增加 到 1000ms 以 上 ， 验 证 了 listener 处 
理 能 力 不 足 。 经 过 权衡 ， 开 发 保留 了 频繁 交互 的 CRM 系 统 和 账户 之 间 的 database link 的 可 持续 会 话 ， 及 时 关闭 来 自 其 他 不 太 频 繁 的 database 
link。 


从 以 上 案例 描述 中 ， 我 们 发 现 以 下 几 点 。 
- listener 的 并 发 处 理 能 力 是 有 限 的 ， 而 且 并 不 是 很 高 。 
- 数据 库 登 录 的 整个 流程 即使 正常 运行 ， 所 需要 的 时 间 也 经 常 达到 180ms 以 上 。 


- 关闭 database link 使 得 database link 访 问 变 成 每 次 访问 都 需要 连接 数据 库 ， 从 而 使 数据 库 登 录 的 响应 时 间 纳 入 了 业务 响应 的 时 间 范 畴 。 


3.2 ”数据 库 登录 流程 的 相关 指标 与 优化 


2.6 节 已 经 介绍 过 数据 库 登 录 流程 的 分 解 如 下 : 
Step 1: 客户 端 登录 请 求 。 

Step 2: listener 处 理 和 响应 。 

Step 3: 服务 进程 派生 。 

Step 4: 进程 初始 化 和 session 初 始 化 。 

Step 5: 用 户 验证 和 权限 判断 。 

Step 6: session 审 计 。 

Step 7: 登录 触发 器 。 

Step 8: 响应 客户 端 。 


对 于 数据 库 登 录 流 程 来 说 ， 业 务 需 求 表述 的 输入 请 求 和 技术 层面 的 输入 请 求 完全 一 致 。 每 次 数据 库 登 录 都 对 应 着 一 次 客户 端 登录 请 求 ， 输 出 响 
应 时 间 自 然 就 是 数据 库 登 录 流 程 的 响应 时 间 了 。 


第 4 章 “流程 分 析 之 数据 访问 处 理 流程 


如 何 高 效 地 访问 数据 库 中 的 数据 ， 这 是 数据 库存 在 的 根本 命题 ， 也 是 数据 库 业务 性 能 优化 的 根本 命题 。SQL 语 句 是 业务 访问 数据 的 基本 语言 ， 
每 个 业务 访问 总 是 由 一 个 或 多 个 持续 的 SQL 语 句 构 成 ， 而 来 自 于 众多 不 同 终端 且 同 时 进行 的 业务 访问 就 构成 了 业务 运行 系统 。 从 本 质 上 来 说 ， 数 据 
访问 处 理 流程 就 是 SQL 语 句 处 理 流程 ， 只 是 众多 的 不 同 SQL 语 句 交织 在 一 起 ， 形 成 了 业务 系统 中 复杂 的 数据 访问 处 理 流程 。 


业务 数据 访问 处 理 


SOLI SOLI SOLI 


SQL2 SOL2 SQL2 


图 4-1 业务 访问 的 层次 关系 图 


图 4-1 描 述 了 业务 数据 访问 流程 的 构成 ， 每 个 人 的 访问 构成 了 一 个 个 session， 众 多 人 的 访问 就 构成 了 不 同 的 session， 它 们 一 起 实现 业务 系统 
的 数据 访问 处 理 和 不 同 的 功能 。 而 每 个 session 又 是 由 一 个 个 不 同 的 持续 或 间歇 运行 的 SQL 构成 。 对 业务 数据 的 访问 处 理 流程 涉及 三 个 不 同 层次 : 


<- SQL 级 别 。 
:Session 级 别 或 个 人 级 别 。 


- 业务 系统 级 别 或 全 局 级 别 。 


4.1 数据 访问 处 理 流程 优化 案例 分 享 


某 商业 银行 RAC 中 的 某 一 个 节点 (节点 不 定 ) 间 拘 性 发 生 CPU 资 源 100% 消 耗 ， 业 务 响应 几乎 挂 起 。 客 户 反映 在 CPU 消 耗 周期 并 没有 太 大 的 业 
务 增 加 ， 检 查 并 比较 正常 周期 和 异常 周期 的 AWR 报 告 ， 发 现 异 常 周期 的 逻辑 读数 量 表现 出 几 倍 的 增长 ， 显 然 某 些 频繁 执行 的 SQL 执行 计划 发 生 了 变 
化 。 进 一 步 检查 Top SQL， 发 现 其 中 一 条 频繁 执行 的 SQL， 其 读 取 每 行 数据 的 逻辑 读数 量 增加 了 近 20 倍 。 分 析 可 以 知道 这 是 因为 Oracle 选 择 了 更 差 
的 索引 提供 服务 。 但 是 从 报告 来 看 ， 即 使 在 业务 影响 缓慢 期 间 ， 单 条 SQL 的 执行 速度 也 很 快 ， 而 且 现场 的 explain 计 划 表 示 选 择 的 索引 正确 。 于 是 再 


针对 SQL 执行 计划 的 历史 进行 比较 ， 发 现 原来 是 执行 计划 发 生 了 变化 ，Oracle 选 择 了 一 个 需要 更 多 逻辑 读 访 问 的 索引 。 最 终 判断 是 由 于 Oracle 
RAC 节 点 的 独立 绑 定 变量 peek 机 制 引起 的 。 通 过 执行 计划 稳固 化 措施 修复 了 该 潜在 问题 。 


很 显然 ， 上 面 的 案例 是 因为 输入 压力 过 大 (logical reads). 导致 了 消耗 资源 (CPU) 过 多 ， 进 而 使 得 输出 响应 变 慢 。 可 以 预见 ， 只 要 CPU 资源 
保持 充足 ， 即 使 选择 了 更 差 的 执行 计划 ， 也 不 会 导致 最 后 的 性 能 障碍 。 在 本 书 中 ，logical reads 总 是 作为 性 能 优化 过 程 中 最 为 重要 的 输入 指标 ， 性 
能 响应 的 输出 总 是 依赖 于 输入 的 变化 。 


4.2 ”数据 访问 处 理 流程 的 分 解 
由 于 业务 数据 访问 处 理 流程 的 基础 组 成 单元 为 SQL 语 句 处 理 ， 因 此 下 面 就 从 SQL 语 句 处 理 的 角度 来 分 析 和 分 解 业务 数据 访问 处 理 流程 。SQL 语 
句 流程 主要 包含 : select、update、delete 和 insert 语 句 ， 除 此 以 外 ，ddl、dcl 和 merge 等 特殊 语句 仅仅 在 需要 的 时 候 会 涉及 ， 不 做 具体 分 析 。 


select 查 询 语句 可 以 说 是 任何 业务 系统 数据 访问 流程 的 基础 所 在 ， 大 部 分 业务 系统 的 查询 和 更 新 负载 比例 都 会 超过 7 : 3， 甚 至 比例 在 9 : 1 以 上 
的 业务 系统 也 比比 丝 是 。 可 以 说 只 要 select 查 询 语句 流程 响应 正常 ， 业 务 系统 很 少 会 出 现 所 谓 的 这 样 或 那样 的 业务 系统 性 能 问题 。 


select 查 询 语句 的 基本 处 理 流程 如 下 : 

Step 1: SQL request， 客 户 端 请 求 SQL 语 句 执 行 。 
Step 2: parse， 制 订 计划 阶段 。 

Step 3: execute, 执行 计划 阶段 。 

Step 4: fetch， 得 到 执行 结果 阶段 。 

Step 5: response， 成 果 响 应 阶段 。 


update、delete 和 insert 语 句 的 处 理 流程 与 select 查 询 流程 类 似 ， 只 是 不 需要 执行 fetch 阶 段 。updateldeletelinsert 语 句 的 基本 处 理 流程 如 


Step 1: SQL request， 客 户 端 请 求 SQL 语 句 执行 。 
Step 2: parse， 制 订 计划 阶段 。 

Step 3: execute， 执 行 计划 阶段 。 

Step 4: response， 成 果 响 应 阶段 。 


在 实际 的 业务 数据 访问 处 理 过 程 中 ， 对 update、delete 和 insert 语 句 进行 变更 处 理 时 ， 只 有 在 发 布 提交 之 后 才 可 以 认为 操作 或 业务 流程 正式 完 
成 。 我 们 需要 在 SQL 语句 流程 中 ， 增 加 一 个 额外 的 commit 流 程 来 完整 地 反映 SQL 语句 的 业务 处 理 情 况 ， 这 样 形成 最 终 的 流程 处 理 过 程 如 下 : 


Step 1: SQL request， 客 户 端 请 求 SQL 语 名 执行。 
Step 2: parse， 制 订 计划 阶段 。 

Step 3: execute， 执 行 计划 阶段 。 

Step 4: fetch (only select) ， 得 到 执行 结果 阶段 。 
Step 5: response， 成 果 响 应 阶段 。 

Step 6: commit， 提 交 变 更 信息 。 


通俗 地 讲 ，SQL 语 句 的 数据 访问 流程 就 是 一 个 计划 的 指定 和 执行 的 过 程 。 我 们 每 个 人 在 生活 中 也 不 断 地 重演 这 个 过 程 ， 每 个 人 在 生活 中 的 成 功 
和 失败 无 非 就 是 制定 的 计划 是 否 合理 以 及 计划 是 否 得 到 有 效 的 执行 而 已 。 


4.3 ”数据 访问 处 理 流程 的 输入 和 输出 


衡量 任意 一 个 流程 处 理 的 基本 单元 就 是 流程 的 输入 和 流程 的 输出 。 从 性 能 的 角度 考虑 ， 在 单位 时 间 之 内 可 以 处 理 更 多 的 输入 压力 ， 就 表示 为 更 
高 的 性 能 。 或 者 单个 输入 的 响应 时 间 最 短 ， 就 表示 为 更 高 的 性 能 。 为 了 使 流程 可 分 析 和 可 优化 ， 一 个 最 为 基本 的 工作 就 是 确定 数据 访问 处 理 流程 的 
输入 和 输出 。 比 如 对 于 具体 的 CRM 业 务 系统 而 言 ， 系 统 或 某 个 营业 员 每 小 时 受理 了 多 少 个 客户 开户 、 变 更 、 销 户 等 操作 。 


44 数据 访问 流程 优化 步骤 


在 有 效 定义 了 数据 访问 流程 的 输入 压力 、 输 出 响应 以 及 业务 特征 指标 之 后 ， 数 据 访问 流程 的 优化 就 成 为 一 个 按部就班 的 过 程 ( 见 图 4-4) 。 


业务 系统 


响应 慢 


ogical reads 
Per Second 大 幅度 


增加 


发 现 导致 logical 访问 流程 分 解 服务 和 等 待 分 析 
reads 增 加 的 业务 | 以 发 现 问 题 发 现 问题 在 于 
和 SQL 语句 phy p reads 子 流 程 处 理 或 者 等 待 
四 加 


发 现 问题 
资源 和 组 件 


通过 更 多 缓存 降低 
physical reads 


SQL 语句 logical 


业务 特征 变化 
" < reads 变 化 


业务 压力 变化 


确认 变化 
或 者 优化 
SQL 


图 4-4 流程 响应 优化 的 基本 步 又 


4.5 ”客户 端 运行 和 响应 阶段 


4.5.1 ” 子 流 程 过 程 性 分 解 


这 里 把 客户 端 运行 和 响应 整个 数据 访问 流程 的 第 一 步 和 最 后 一 步 合并 在 一 起 来 分 析 。 
SQL 语句 请 求 的 执行 过 程 如 下 。 


1 


— 


user process 发 布 SQL 语句 。 

2) 客户 端 语 句 进行 语法 分 析 。 

3) 客户 端 通过 socket 发 送 SQL 语 句 。 

4) 网 络 传输 。 

5) server process 接 收 SQL 语 句 。 

6) server process 把 SQL 语句 送 入 parse 流 程 。 
SQL 语句 将 响应 结果 发 送 给 客户 端的 过 程 如 下 。 
1) server process 从 fetch 中 获得 结果 。 

2) 运行 结果 数据 送 到 网 络 缓存 。 


3 


— 


server process 开 始 等 待 响应 。 
4) 网 络 传递 数据 。 


5 


— 


user process 接 收 数据 。 

6) 响应 信息 给 server process。 

7) server process 继 续 从 fetch 中 获得 结果 。 
8) 重复 过 程 直到 fetch 结 束 。 


9) user process 执 行 客户 端 业 务 。 


10) server process 开 始 等 待 请 求 。 


46 SQL 语句 分 析 阶 段 (parse 阶 段 ) 


SQL parse 的 处 理 过 程 是 Oracle 数 据 库 中 最 为 重要 的 计划 制定 阶段 ， 其 是 否 有 效 和 高 效 最 大 程度 决定 了 SQL 语句 的 执行 是 否 高 效 。 这 里 不 讨论 
为 什么 没有 产生 高 效 正确 的 执行 计划 ， 而 是 分 析 parsing 过 程 的 高 效 运行 过 程 。 


4.7 ”SQL 语句 执行 阶段 (execute 阶 段 ) 


一 条 SQL 语句 在 经 过 parse 阶 段 之 后 ， 制 订 了 执行 计划 ， 接 下 来 就 需要 按照 计划 去 执行 SQL 语句 了 。 从 实际 经 验 可 以 知道 ， 一 个 计划 执行 是 否 
有 效 ， 主 要 在 于 以 下 两 点 。 


o 制订 的 执行 计划 是 否 准确 。 
“ 执行 是 否 有 效 。 


计算 机 的 执行 和 人 类 执行 不 同 ， 它 是 一 系列 的 无 差错 动作 ， 基 本 不 会 发 生 消极 念 工 等 行为 ， 其 执行 是 否 有 效 ， 关 键 在 于 其 执行 计划 是 否 有 效 。 


由 于 fetch 过 程 和 execute 过 程 的 不 可 分 割 ， 因 此 本 章 论述 的 execute 阶 段 包含 execute 过 程 和 fetch 过 程 。 


fetch 过 程 是 把 取得 的 结果 集 从 SGA 区 拷贝 到 PGA 区 ， 不 过 ， 仅 仪 是 查询 语句 存在 fetch 过 程 ， 对 于 更 新 语句 不 存在 fetch 过 程 。 每 次 fetch 结 束 
必然 伴随 着 一 次 客户 端 进程 和 服务 进程 的 一 次 网 络 交互 ， 显 然 fetch 次 数 对 网 络 交互 具有 重大 影响 。 


下 面 来 看 fetch 次 数 对 逻辑 读 是 否 会 产生 比较 大 的 影响 。 


从 图 4-38~ 图 4-40 可 以 看 到 ，fetch 次 数 对 响应 和 logical reads 产 生 了 巨大 的 影响 。 对 于 同样 的 语句 返回 73566 行 记录 : 每 次 fetch 获 取 一 行 记 
录 ， 共 执行 fetch 次 数 为 73566 次 ， 执 行 逻 辑 读 为 37271 次 。 每 次 fetch 获 取 100 行 记录 ， 共 执行 fetch 次 数 为 737 次 ， 执 行 逻 辑 读 为 1639 次 。 显 然 ， 
每 次 fetch 记 录 数 的 不 同 对 逻辑 读 具 有 重大 的 影响 ， 而 fetch 次 数 等 于 网 络 交互 次 数 。 同 样 也 可 以 看 到 ， 在 fetch 记 录 数 为 500 的 时 候 ， 远 辑 读 的 下 降 
并 不 明显 。 这 个 结果 可 以 理解 为 ， 当 每 次 fetch 的 记录 数 超过 每 个 数据 块 包含 的 行 数 的 时 候 ， 逻 辑 读 会 基本 维持 不 变 ， 过 多 的 逻辑 读 是 由 于 重复 读 
取 某 个 数据 块 造成 的 。 


很 多 时 候 ， 应 用 程序 默认 的 fetch 次 数 为 1， 可 以 认为 这 在 绝 大 部 分 情况 下 是 不 合理 的 ， 需 要 设置 合理 的 fetch 记 录 值 。 


set arraysize 1 

set autotrace on 

set autotrace traceonly 
select * from sys.objĝ$; 


已 选择 ?3566 行 。 


Plan hash value: 23114516808 


Cost €XxCPU»! Time 


SELECT STATEMENT 5947K 250 «2»1 00:00:04 
TABLE ACCESS FULL! OBJ$ 5947K ! 250 (2i 00:00:04 


recursive calls 

db block gets 

consistent gets 

physical reads 

redo size 

13365415 bytes sent via SQLxNet to client 

405122 bytes received via SQL*Net from client 
36784 SQLxNet roundtrips to/from client 

sorts memory> 

sorts 《disk> 

rows processed 


图 4-38 attaysize=1 下 的 SQL 响应 和 相关 统计 


BQL> set arraysize 100 
QL> select * from sys.objĝ; 


HD ytix735661T. 


ATi 


Plan hash value: 2311451600 


Cost xCPU>2! Time 


SELECT STATEMENT 5947K i 258 《2>1 00:00:04 
TABLE ACCESS FULL! OBJ$ 5947K; PAS 2271 00:00:04 


recursive calls 

db block gets 

consistent gets 

physical reads 

redo size 

6668673 bytes sent via SQLxNet to client 

86805 bytes received via SQLxNet from client 
737 SQLxNet roundtrips to/from client 

sorts (memory? 

sorts (disk? 

rows processed 


图 4-39 attaysize=100 下 的 SQL 响应 和 相关 统计 


SQL» set arraysize 588 
SQL> select x from sys.0his; 


已 选择 ?3566 行 。 


Plan hash value: 2311451600 


Cost 《ZXCPU> 1 Time 


SELECT STATEMENT 5947K; 250 (2i 00:00:04 
TABLE ACCESS FULL: OBJ$ 5947Ki 250 (2)i 00:00:04 


recursive calls 

db block gets 

consistent gets 

physical reads 

redo size 

6551305 bytes sent via SQLxNet to client 

2137 bytes received via SQLxNet from client 
149 SQLxNet roundtrips to/from client 

sorts memory> 

sorts (disk? 

rows processed 


图 4-40 attaysize=500 下 的 SQL 响应 和 相关 统计 


提交 过 程 相对 比较 简单 ， 基 本 执行 以 下 步骤 。 

Step 1: 通知 Lgwr 进 程 把 事务 相关 的 Log Buffer 写 入 Online Redo logfile, 

Step 2: 等 待 Lgwr 通 知 完成 事务 写 或 者 主动 查询 是 否 完成 ， 期 间 表现 为 Log file sync 等 待 事件 。 

Step 3: 在 回 滚 段 事务 表 中 标记 事务 为 commit。 

Step 4 (n) : 在 事务 涉及 的 data block 中 标记 block 为 commit。 

Step 5: 释放 涉及 的 事务 锁 资 源 以 及 latch 资 源 。 

由 于 涉及 的 事务 data block 可 能 数量 极为 庞大 ，Oracle 为 了 加 速 Commit 过 程 ， 经 常会 采用 延迟 清理 ， 放 弃 直接 在 block 中 标记 commit 信 息 。 
可 以 看 到 ，commit 过 程 主要 就 在 于 等 待 |gwr 进 程 完成 事务 写 ， 其 他 过 程 对 于 lgwr 写 来 说 是 微不足道 的 。 


下 面具 体 来 看 看 commit 会 发 生 些 什么 ， 代 码 如 图 4-41 所 示 。 


SQL» select sys context('userenv','sid') from dual; 
SYS CONTEXT ('USERENV', ' SID') 


SQL» update aaa set name-'BBBB'; 
1 row updated 


SQL» commit; 
Commit complete 


SQL» create table sesstatl as select * from v$sesstat where sid=1154; 
Table created 


SQL» create table sesstimel as select * from v$sess time model where sid-1154; 
Table created 


SQL» create table sesstatl as select * from v$sesstat where sid-1154; 
create table sesstati as select * from v$sesstat where sid-1154 
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SQL» create table sesstat2 as select * from v$sesstat where sid-1154; 
Table created 


SQL» create table sesstime2 as select * from v$sess time model where sid-1154; 
Table created 


SQL» select * from (select s3.NAME,s2.value-si1.value value from v$statname s3,sesstatl s1,sesstat2 s2 
2 where si.statisticé-s2.statisticfk and si.statisticfé-s3.STATISTIC£) where value »0 order by value desc 
3 ; 

IMU undo allocation size 1368 

redo size 604 

bytes received via SQL*Net from client 277 

bytes sent via SQL*Net to client 171 

db block changes 

non-idle wait count 

user calls 

enqueue releases 

commit cleanouts 

commit cleanouts successfully completed 

calls to kcmgas 

redo entries 

IMU commits 

parse count (total) 

parse count (hard) 

redo synch writes 

db block gets from cache 

db block gets 

messages sent 

session logical reads 

recursive calls 

SQL*Net roundtrips to/from client 

opened cursors cumulative 

user commits 

24 rows selected 


SQL» select * from (select s2.stat name,s2.value-sl.value value from sesstime2 s2,sesstimel s1 
where s2.stat id-s1.stat id) where Value>0 


Boe p p» dS dS de dS dS jS. I8. S I8 IS I I.N) IND) OD 


parse time elapsed 
SQL» select s2.event,s2.total waits-sl.total waits total waits,s2.time waited micro-si.time waited micro tim 
2 from sesseventl si,sessevent3 s2 where s2.event*sl.event; 
TOTAL WAITS TIME WAITED MICRO 


Disk file operations I/O 
SQL*Net message to client 
SQL*Net message from client 68658125 


图 4-41 ”commit 过 程 的 相关 测试 和 验证 


从 图 4-41 可 以 看 到 ， 和 前 面 描述 的 基本 一 致 ， 主 要 是 写 了 redo size。 当 然 还 可 以 看 到 IMU 的 相关 信息 ， 在 启用 了 IMU 之 后 ，commit 过 程 会 
一 个 IMU commit 过 程 。 可 以 看 到 ，1MU 通 过 批量 写 降 低 了 undo block 写 次 数 和 并 发 性 冲突 ， 事 实 上 这 对 commit 过 程 会 有 影响 ，IMU 的 具体 分 析 
和 改善 在 组 件 章节 进行 描述 ， 这 里 不 再 展开 。 由 于 响应 过 于 快捷 ， 我 们 甚至 没有 观察 到 任何 log file sync 等 待 事件 。 


第 5 章 ”资源 


关于 流程 、 资 源 和 组 件 的 性 能 优化 ， 前 面 已 经 比较 详细 地 讲述 了 流程 。 流 程 是 Oracle 系 统 性 能 优化 的 核心 所 在 ， 资 源 和 组 件 是 用 来 支撑 流程 的 
运行 的 。 从 本 章 开始 ， 将 针对 资源 进行 介绍 ， 事 实 上 ， 在 前 面 每 个 流程 处 理 环节 中 都 有 涉及 资源 的 小 节 (描述 支撑 该 流程 运行 的 资源 供给 ) 。 


流程 和 组 件 都 有 比较 明晰 的 定义 ， 而 资源 则 是 一 个 相对 广泛 描述 的 术语 。 通 常 ， 我 们 把 流程 和 组 件 之 外 的 供给 物 都 统称 为 资源 。 总 体 而 言 ， 资 
源 包含 物理 硬件 级 别提 供 的 资源 和 软件 级 别 配置 提供 的 资源 。 对 于 Oracle 数 据 库 而 言 ， 任 何 资源 都 是 逻辑 性 资源 ， 也 就 是 说 是 基于 配置 的 资源 ， 只 
不 过 基于 配置 的 资源 其 真实 的 能 力 呈 现 需 要 真实 的 物理 硬件 资源 来 加 以 支撑 。 

在 本 书 中 ， 大 致 把 资源 分 为 以 下 三 大 类 。 

(1) 简单 的 资源 供给 类 

简单 的 资源 供给 类 总 是 和 物理 硬件 密切 相关 的 ， 这 里 主要 关注 的 资源 包含 CPU、 内 存 、IMO 子 系统 和 网 络 子 系统 。 

(2) 并 发 性 控制 资源 类 

并 发 性 控制 资源 类 总 是 体现 为 软 资源 ， 其 不 仅 和 硬件 资源 相关 ， 更 多 地 体现 了 操作 系统 和 Oracle 数 据 库 是 否 具 有 高 效 的 资源 供给 能 力 。 这 里 主 


要 关注 的 并 发 性 资源 包括 锁 、buffer lock、latch 和 mutex。 
(3) 配置 类 限制 性 资源 


配置 类 限制 性 资源 是 一 种 简单 的 配置 型 资源 ， 在 绝 大 部 分 场景 下 不 会 演化 为 性 能 障碍 ， 比 如 进程 数量 、 文 件 句柄 数量 ， 等 等 。 本 书 中 不 关注 这 
类 资源 ， 在 配置 充足 的 情况 下 ， 这 类 资源 出 现 问题 往往 意味 着 操作 系统 或 数据 库 本 身 的 处 理 能 力 不 足 ， 不 在 本 书 讨论 范畴 之 中 。 


5.1 简单 的 资源 供给 类 


简单 的 资源 供给 类 主要 指 硬件 资源 ， 如 CPU、 内 存 、 磁 盘 和 网 络 资源 等 。 


5.2 ”并 发 性 资源 


对 于 Oracle 数 据 库 来 说 ， 一 致 性 是 其 存在 的 根本 原因 ， 并 发 性 资源 的 高 效 获得 是 保证 Oracle 业 务 系统 高 性 能 运行 的 关键 所 在 。 虽 然 我 们 经 常会 
说 多 任务 的 操作 系统 、 并 发 运行 的 数据 库 等 ， 但 事实 上 几乎 不 存在 真正 同时 运行 的 操作 和 业务 。 特 别 是 对 于 Oracle 业 务 系统 而 言 ， 所 有 的 任务 都 是 
串 行 的 ， 都 需要 获得 lock 或 者 latch 等 并 发 性 资源 以 保证 排他 运行 。 如 何 高 效 获 取 和 释放 并 发 性 资源 就 成 为 设计 和 优化 一 个 高 效 的 Oracle 业 务 系统 
的 关键 所 在 。 


第 6 章 ”资源 供给 : CPU 


6.1 简单 案例 分 享 


某 运营 商 的 经 营 分 析 系 统 ，ETL 完 成 时 间 不 能 让 人 满意 ， 期 望 在 6: 30， 最 晚 7: 00 完 成 的 ETL 作 业 总 是 在 9: 00 多 才 完 成 ， 老 板 意见 很 大 ， 信 
息 化 部 门 的 压力 很 大 。 这 是 一 个 DB2 数 据 库 ， 服 务 供应 商 给 出 了 优化 SQL 的 解决 方案 ， 昌 然 笔 者 不 懂 DB2， 但 在 简单 看 了 优化 的 SQL 方案 后 ， 直 觉 
认为 该 优化 方案 是 无 效 的， 不 会 产生 效果 。 事 实 上 ， 服 务 商 在 辛苦 了 半 个 月 之 后 确实 之 无 收获 。 笔 者 看 了 他 们 的 系统 后 ， 建 议 进行 简单 的 调整 ， 相 
言 可 以 实现 ETL 作 业 缩 减 2 小 时 的 时 间 。 笔 者 所 建议 的 措施 非常 简单 ， 只 是 把 ETL 作 业 进 行 了 均匀 调度 ， 使 其 平稳 地 分 布 在 从 10: 00 开 始 的 时 间 范 围 
内 ， 而 不 是 像 原来 那样 空闲 几 个 小 时 ， 运 行 几 个 小 时 ， 然 后 又 空闲 一 段 时 间 。 在 原先 的 程序 中 ， 由 于 同时 派生 的 进程 运行 太 多 ， 导 臻 CPU 和 I/O 都 
100% 忙 碌 ， 达 到 硬件 限制 。 只 要 让 资源 适当 分 布 ， 就 可 以 降低 在 CPU 和 IO 资源 的 冲突 ， 最 大 程度 地 利用 资源 ， 从 而 提高 程序 响应 速度 。 最 后 开发 
商 依照 笔者 的 建议 调整 了 运行 时 间 和 并 发 控制 ， 有 意识 地 安排 程序 错开 运行 ， 使 得 ETL 速 度 平稳 地 加 快 了 2 个 多 小 时 ， 达 成 了 优化 目标 。 可 以 看 到 ， 
这 个 案例 很 清晰 地 说 明了 优化 方法 的 通用 性 。 


第 6 章 ”资源 供给 : CPU 


6.1 简单 案例 分 享 


某 运 营 商 的 经 营 分 析 系 统 ，ETL 完 成 时 间 不 能 让 人 满意 ， 期 望 在 6: 30， 最 晚 7: 00 完 成 的 ETL 作 业 总 是 在 9: 00 多 才 完 成 ， 老 板 意 见 很 大 ， 信 
息 化 部 门 的 压力 很 大 。 这 是 一 个 DB2 数 据 库 ， 服 务 供应 商 给 出 了 优化 SQL 的 解决 方案 ， 昌 然 笔 者 不 懂 DB2， 但 在 简单 看 了 优化 的 SQL 方案 后 ， 直 觉 
认为 该 优化 方案 是 无 效 的， 不 会 产生 效果 。 事 实 上 ， 服 务 商 在 辛苦 了 半 个 月 之 后 确实 之 无 收获 。 笔 者 看 了 他 们 的 系统 后 ， 建 议 进行 简单 的 调整 ， 相 
言 可 以 实现 ETL 作 业 缩 减 2 小 时 的 时 间 。 笔 者 所 建议 的 措施 非常 简单 ， 只 是 把 ETL 作 业 进 行 了 均匀 调度 ， 使 其 平稳 地 分 布 在 从 10: 00 开 始 的 时 间 范 围 
内 ， 而 不 是 像 原来 那样 空闲 几 个 小 时 ， 运 行 几 个 小 时 ， 然 后 又 空闲 一 段 时 间 。 在 原先 的 程序 中 ， 由 于 同时 派生 的 进程 运行 太 多 ， 导 臻 CPU 和 I/O 都 
100% 忙 碌 ， 达 到 硬件 限制 。 只 要 让 资源 适当 分 布 ， 就 可 以 降低 在 CPU 和 IO 资源 的 冲突 ， 最 大 程度 地 利用 资源 ， 从 而 提高 程序 响应 速度 。 最 后 开发 
商 依照 笔 者 的 建议 调整 了 运行 时 间 和 并 发 控制 ， 有 意识 地 安排 程序 错开 运行 ， 使 得 ETL 速 度 平稳 地 加 快 了 2 个 多 小 时 ， 达 成 了 优化 目标 。 可 以 看 到 ， 
这 个 案例 很 清晰 地 说 明了 优化 方法 的 通用 性 。 


6.2 ”CPU 的 特殊 性 


业务 系统 的 运行 依赖 于 资源 供给 ， 而 Oracle 数 据 库 所 有 的 资源 又 都 来 源 于 OS，OS 所 有 的 资源 则 来 源 于 依赖 的 硬件 ， 比 如 CPU、memory、 


network, IO Subsystem 等 。CPU 可 以 说 是 其 中 最 重要 的 资源 。CPU 一 一 中 央 处 理 器 ， 在 所 有 部 件 中 唯一 一 个 主动 性 部 件 ， 其 他 任何 部 件 都 依赖 
于 CPU 的 调度 ， 属 于 被 动 响应 。 可 以 看 到 ，Oracle 把 CPU 运行 部 分 表示 为 服务 时 间 ， 其 他 部 分 表示 为 等 待 时 间 。 


CPU 往往 是 主机 设备 中 最 为 昂贵 的 部 件 ，CPU 是 所 有 硬件 资源 中 最 不 具有 柔韧 性 的 部 件 ， 你 几乎 无 法 为 其 扩容 ， 也 很 难 因为 资源 不 足 去 增加 


CPU 数量 ， 或 者 CPU 主 频 不 够 去 增加 主 频 。 作 为 一 个 性 能 优化 者 ， 几 乎 不 需要 去 关注 CPU 的 运行 细节 ， 特 别 是 在 数据 库 应 用 中 ，CPU 的 能 力 事实 上 
取决 于 内 存 系统 ， 因 为 绝 大 部 分 操作 是 内 存 操作 而 非 是 运算 操作 。 


63 CPU 的 工作 和 运行 性 能 的 衡量 


6.3.1 CPU 的 主要 工作 


在 Oracle 业 务 系统 中 ，CPU 主 要 承担 以 下 工作 : 


. 运算 ; 


' 内 存 操作 ; 
“ 各 种 调用 ; 
:引擎 转换 ; 
:页面 交换 ; 
- 上 下 文 切换 ; 
:响应 中 断 ; 
“ 网 络 处 理 。 


当然 ， 也 可 以 说 CPU 参与 一 切 工作 ， 任 何 工作 没有 CPU 的 参与 都 无 法 完成 。 


6.4 CPU 资源 的 主要 衡量 指标 


6.4.1 ”CPU 的 主要 性 能 衡量 指标 


CPU 的 主要 性 能 衡量 指标 如 下 。 
: CPU 利用 率 : 衡量 CPU 资源 的 利用 程度 ， 由 CPU user 和 CPU sys 构 成 。 
-CPU 利用 率 : =CPU user CPU sys 


| CPU queue (运行 队列 ) : 由 于 一 个 CPU 在 某 一 时 刻 只 能 为 一 个 用 户 进程 提供 服务 ， 因 此 运行 队列 中 的 其 他 进程 需要 等 待 之 前 的 进程 完成 工 
作 之 后 才能 得 到 服务 。 


' 进程 fo 全 次 数 : 进程 fo 引 极 其 消耗 CPU 资源 ， 这 部 分 CPU 资源 会 反应 在 CPU sys 之 中 。 


- 上 下 文 切换 (context switchs) 次 数 : 在 CPU 调度 的 过 程 中 会 不 断 地 涉及 上 下 文 切 换 ， 尤 其 是 进程 在 不 同 CPU 之 间 进 行 调度 的 时 候 ， 此 时 会 涉 
及 CPU cache 进 程 信息 的 释放 和 重 载 。 该 指标 同样 仅仅 影响 到 CPU sys 部 分 。 


:中断 (interrupts) 次 数 : 每 次 中 断 都 需要 进行 相关 引擎 的 转换 ， 都 需要 CPU 内 核 进 行 处 理 。 该 指标 仅仅 影响 到 CPU sys 部 分 。 


65 几 个 CPU 资源 贡 见 问题 的 讨论 


6.5.1 CPU 资源 的 100% 利 用 率 
CPU 资 源 的 100% 利 用 率 几乎 总 是 成 为 业务 系统 性 能 不 佳 的 一 个 证 据 ， 甚 至 依据 该 规则 很 多 人 会 建议 用 户 远离 100%， 要 求 以 70% 甚 至 50% 的 利 
用 率 作 为 CPU 资源 优化 的 标准 。 事 实 上 ， 从 前 面 的 分 析 中 可 以 知道 ， 从 性 能 的 角度 来 考虑 ， 这 个 观点 是 错误 的 。 


从 前 面 的 分 析 已 经 知道 ， 只 要 可 以 自由 地 获得 CPU 资源 ，50% 的 CPU 利用 率 和 95% 的 CPU 利用 率 ， 从 用 户 响 应 的 角度 来 看 没有 任何 区 别 。 而 且 


经 过 优化 的 系统 往往 是 MO 瓶 颈 ， 而 经 过 优化 的 系统 应 该 是 CPU 瓶颈 。 


那 为 什么 要 求 高 峰 期 CPU 运行 在 80%、709% 甚 至 50% 会 成 为 一 个 流行 的 观点 呢 ?》 有 些 用 户 甚至 会 因为 出 现 了 50% 的 CPU 利用 率 而 忧心 名 刷 ， 担 
心性 能 不 佳 。 究 其 原因 ， 最 主要 的 称 伯 是 在 于 CPU 部 件 的 昂贵 而 导致 其 可 扩容 性 很 差 ， 用 户 为 了 未 来 的 业务 增长 而 保留 了 大 量 的 CPU 资源 ， 最 终结 
果 往 往 是 主机 已 经 被 淘汰 了 ，CPU 利 用 率 依然 在 60% 左 右 。 


1009% 以 下 的 CPU 利用 率 ， 包 括 959%、909% 甚 至 98% 的 CPU 利用 率 都 不 是 业务 系统 性 能 不 佳 的 有 效 证 据 ， 但 是 100% 的 CPU 利用 率 在 绝 大 部 分 
场合 可 以 成 为 业务 系统 性 能 不 佳 的 佐证 。 因 为 在 100% 的 CPU 利用 率 下 ， 我 们 不 知道 CPU 是 刚好 处 于 满 负载 运行 还 是 由 于 CPU 资源 限制 导致 业务 无 
法 全 速 运行 。 


事实 上 ， 在 100% 的 CPU 利用 率 场景 下 是 否 存 在 CPU 资源 不 足 的 问题 ， 可 以 通过 以 下 三 个 方面 来 判断 。 
1) CPU 运行 队列 是 否 在 可 接受 的 范畴 之 内 。 


在 CPU 利 用 率 为 100% 的 前 提 下 ， 大 多 数 情况 下 会 出 现 CPU 运 行 队列 过 高 的 情况 。 如 果 CPU 运 行 队列 依然 保持 在 合理 的 范畴 之 内 ，100% 的 利 
用 率 引起 性 能 问题 的 几率 相对 会 比较 少 。 


2) CPU sys 的 占用 比例 是 否 偏 高 。 


有 些 场 合 下 CPU 100% 利 用 率 是 源 于 CPU sys， 特 别 是 业务 系统 调度 不 当 的 时 候 ， 这 时 会 由 于 众多 的 fork 操 作 导 致 CPU sys 甚 至 会 达到 90% 以 
上 。 即 使 在 CPU 利 用 率 在 100% 以 下 ，CPU sys 的 占用 率 过 高 总 是 意味 着 性 能 问题 ， 因 为 这 意味 着 有 更 多 的 操作 需要 完成 。 


3) CPU iowait 的 占用 比例 是 否 偏 高 。 
CPU iowait 的 占用 比例 偏 高 意味 着 CPU 在 等 待 MO 子 系统 完成 任务 ， 处 于 相对 空闲 的 状态 。 


在 实践 操作 中 ，CPU 基 线 管理 是 判断 CPU 资源 有 效 性 的 最 有 效 依据 。 建立 CPU 基 线 ， 与 以 前 的 进行 比较 ， 确 定 CPU 利 用 率 是 否 存在 变 
化 ，100% 的 CPU 利用 率 在 存在 基线 数据 的 前 提 下 很 容易 判断 出 它 是 否 是 性 能 问题 的 根源 。 


6.6 CPU 资源 优化 的 目标 和 道路 


6.6.1 CPU 资源 问题 的 场景 和 优化 道路 


CPU 作 为 一 种 简单 的 资源 供给 ， 形 成 的 CPU 资 源 压力 主要 来 源 于 以 下 几 个 不 同方 面 ， 我 们 只 要 针对 这 些 场景 做 针对 性 处 理 即 可 ( 见 图 6-26) . 
1.CPU 运 行 的 环境 出 现 问题 


CPU 的 高 效 运行 需要 建立 在 一 定 的 环境 之 下 ， 脱 离 了 运行 环境 自然 会 引起 运行 效率 降低 。 最 为 典型 的 场景 为 CPU 温度 过 高 ， 不 仅 会 导致 CPU 运 
行 效率 下 跌 ， 甚 至 会 引起 主机 系统 宕 机 。 


2.CPU 出 现 运 行 故障 


局 部 CPU 出 现 故 障 导致 主机 系统 的 CPU 总 处 理 能 力 不 足 ， 自 然 也 就 出 现 了 CPU 资源 不 足 问 题 。 


CPU 问题 


降低 CPU 消耗 分 布 CPU 压 力 


提高 CPU 
处 理 效率 


作业 调度 
时 间 分 布 


CPU 之 间 
分 布 


图 6-26 CPU 优化 方法 和 步骤 


3.CPU 上 的 输入 压力 过 大 
CPU 的 过 多 处 理 导致 CPU 利用 率 为 100%， 运 行 队列 等 待 过 长 。 
4.CPU 上 CPU sys 输 入 压力 过 大 
CPU sys 的 输入 压力 过 大 ， 比 如 进程 fork 次 数 过 多 、 上 下 文 切换 过 多 ， 等 等 。 
5. 局 部 进程 的 CPU 输入 压力 过 大 
当 一 些 共享 进程 出 现 CPU 输 入 压力 过 大 的 时 候 ， 自 然 就 导致 了 全 局 性 能 的 恶化 ， 比 如 Oracle 后 台 进 程 、listener 进 程 ， 等 等 。 
对 于 Oracle 业 务 系统 ， 依 据 上 述 场景 主要 采用 以 下 优化 方法 来 提高 性 能 。 
6. 降 低 CPU 的 输入 压力 


降低 CPU 的 输入 压力 是 CPU 资源 优化 的 根本 之 道 ， 降 低 CPU 资 源 使 用 的 主要 目的 是 使 CPU 的 使 用 率 落 入 正常 范围 和 运行 队列 之 内 ， 使 CPU 面 
向 用 户 全 速 运转 。 


7. 分 布局 部 的 CPU 输入 压力 


很 多 时 候 ， 我 们 会 发 现 CPU 压力 主要 出 现在 有 限 的 几 个 进程 之 上 。 由 于 Oracle 是 多 进程 体系 结构 ，Oracle 并 不 会 把 CPU 开销 均匀 地 分 布 到 其 他 
空闲 的 CPU 之 上 ， 因 此 ， 把 高 压力 的 CPU 资源 部 分 转移 到 空闲 的 CPU 资源 区 运行 ， 自 然 就 成 为 一 种 廉价 有 效 的 解决 方案 。 


8. 提 高 CPU 处 理 效率 


有 些 时 候 ，CPU 资 源 是 无 法 通过 分 布 去 完成 优化 的 。 这 时 ， 需 要 充分 提高 CPU 的 处 理 效率 。 提 高 处 理 效率 主要 通过 两 个 环节 去 完成 : 一 是 减少 
CPU 之 间 的 上 下 文 切 换 ; 二 是 使 每 个 CPU 时 间 分 片 饱 和 运转 。 


9. 合 理 调度 平缓 化 CPU 使 用 


在 相当 多 的 业务 系统 会 出 现 锯齿 形 的 CPU 资源 消耗 ， 显 然 这 种 CPU 资源 消耗 是 因为 调度 不 当 引起 的 。 


67 ”CPU 资源 优化 案例 


1. 主 机 房 空 调 系统 故障 导致 CPU 温度 过 高 


某 运营 商 报 告 计 费 系统 运行 性 能 很 差 ， 所 有 的 操作 都 感觉 比较 缓慢 ， 已 确认 是 在 某 时 刻 性 能 开始 慢 慢 降低 的 ， 此 时 业务 并 没有 发 生 任何 变化 。 
检查 系统 和 配置 ，Oracle 发 生 了 大 量 的 buffer busy waits 及 latch 等 待 事件 ， 计 算 logical reads 效 率 感觉 logical reads 的 处 理 响应 不 足 。 检 查 虚拟 
内 存 交换 ， 表 现 尚 可 。 检 查 syslog 发 现 CPU 温度 告警 ， 进 一 步 发 现 是 因为 主机 房 空 调 故障 导致 。 业 务 响应 缓慢 的 原因 自然 是 CPU 温度 升 高 导致 CPU 
处 理 能 力 下 降 ， 也 许 在 检查 全 局 性 故障 的 时 候 ， 首 先 检 查 硬 件 错误 是 一 个 好 顺序 。 


2. 高 频 的 变量 绑 定 导致 CPU 资源 开销 很 高 


某 运 营 商 信用 审核 业务 总 是 延迟 而 且 CPU 占用 率 居 高 不 下 ， 要 求 发 送 业 务 代码 过 来 查看 ， 发 现存 在 频率 极 高 的 变量 绑 入 和 绑 出 操作 。 处 理 措施 
当然 就 非常 简单 了 ， 采 用 Bulk collect 和 forall 批 量 绑 定 技 术 ，CPU 开 销 从 100% 迅 速 下 降 到 20%， 同 时 业务 运行 速度 提高 5 倍 以 上 。 


3 .频繁 的 SQL-PLSQL 引 警 转换 使 性 能 受 损 


某 城 商行 某 特定 业务 运行 比较 缓慢 ， 总 是 无 法 在 有 限 的 时 间 内 完成 ， 根 据 发 送 的 业务 代码 ， 发 现 高 频率 的 SQL 语句 中 调用 了 PLSQL 函 数 ， 特 别 
是 该 PLSQL 函 数 作用 在 几 王 万 行 表格 的 所 有 行 上 。 知 道 了 问题 之 后 修正 当然 也 很 简单 ， 把 PLSQL 函 数 从 SQL 语句 迁移 到 PLSQL 代 码 块 中 ， 业 务 运 行 
速度 提高 1 倍 多 ， 同 时 CPU 开销 大 幅度 下 降 。 


4 业务 的 不 合理 调度 导致 业务 受 损 


某 运 营 商 总 是 出 现 CPU 资 源 开销 居 高 不 下 ， 检 查 系 统 ， 发 现 消耗 资源 很 大 的 SQL 语 句 来 源 于 几 个 频繁 调度 的 批 处 理 作业 程序 ， 这 些 程 序 每 30 秒 
调度 一 次 ， 每 次 调度 12 个 。 与 业务 进行 具体 沟通 ， 确 定 是 否 真 正 需要 如 此 频繁 地 调度 作业 ， 最 后 确定 没有 必要 如 此 频繁 调度 作业 ， 修 正 为 每 5 分 钟 
调度 一 次 ， 并 且 在 每 个 作业 调度 之 间 休 息 2 秒 钟 ， 使 进程 派生 平缓 避免 过 量 的 CPU sys 操 作 。 

5.listener 进 程 CPU 居 高 不 下 


某 运营 商 的 业务 系统 连接 数据 库 很 慢 ， 某 些 需要 通过 dblink 访 问 的 业务 也 感觉 比较 缓慢 。 检 查 listener 进 程 CPU， 接 近 100%，tnsping 响 应 时 
间 超 过 200ms。 显 然 listener 进 程 的 输入 压力 已 经 超过 了 listener 进 程 的 处 理 能 力 ， 具 体 原因 是 业务 变更 的 时 候 启动 了 dblink close 操 作 。| 临 时 性 的 
解决 方案 为 启动 多 个 listener 进 程 进行 业务 分 担 以 平衡 CPU 资 源 ， 主 要 为 针对 主要 的 db-link 服 务 和 主要 的 应 用 服务 器 各 自 增 加 特定 的 listener 进 程 
提供 专门 服务 ， 分 担 listener 进 程 压力 ， 使 之 分 布 到 不 同 的 CPU 之 上 ， 业 务 恢复 正常 。 


第 7 章 ”资源 供给 : 内 存 和 虚拟 内 存 


7.1 简单 案例 分 享 


某 客户 运行 在 HP UNIX 上 的 Oracle 数 据 库 周 期 性 地 出 现 业 务 系统 性 能 下 降 的 情况 ， 甚 至 导致 业务 系统 挂 起 ， 每 次 都 需要 重新 启动 服务 器 来 解决 
之 。 昌 然 服务 器 拥有 很 大 的 内 存 ， 但 数据 库 所 分 配 的 内 存 并 不 是 太 大 ， 之 所 以 会 出 现 上 述 问题 ， 主 要 是 因为 交换 空间 配置 得 太 少 ， 使 得 进程 派生 受 
限 ， 进 而 导致 进程 空间 的 内 存 不 断 被 交换 到 磁盘 上 ， 致 使 性 能 下 降 甚 至 挂 起 。 这 类 故障 在 10 年 前 极为 普遍 ， 几 乎 每 个 HP-UX 用 户 都 会 遇 到 。HP- 
UX 在 进程 派生 的 时 候 ， 需 要 在 交换 空间 复制 一 份 进程 数 据 ， 由 于 交换 空间 的 不 足 ， 导 致 HP-UX 仅 仪 可 以 使 用 不 超过 交换 空间 的 内 存 空 间 ， 也 就 是 
说 ， 即 使 你 有 32GB 内 存 ， 如 果 交 换 空间 只 有 2GB， 那 也 只 能 使 用 2GB 的 进程 内 存 空间 。 但 是 现在 ， 可 能 随 着 操作 系统 特性 的 变更 ， 这 类 故障 已 消 
失 了 。 


第 7 章 ”资源 供给 : 内 存 和 虚拟 内 存 


7.1 简单 案例 分 享 


某 客户 运行 在 HP UNIX 上 的 Oracle 数 据 库 周 期 性 地 出 现 业 务 系统 性 能 下 降 的 情况 ， 甚 至 导致 业务 系统 挂 起 ， 每 次 都 需要 重新 启动 服务 器 来 解决 
之 。 昌 然 服务 器 拥有 很 大 的 内 存 ， 但 数据 库 所 分 配 的 内 存 并 不 是 太 大 ， 之 所 以 会 出 现 上 述 问题 ， 主 要 是 因为 交换 空间 配置 得 太 少 ， 使 得 进程 派生 受 
限 ， 进 而 导致 进程 空间 的 内 存 不 断 被 交换 到 磁盘 上 ， 致 使 性 能 下 降 甚 至 挂 起 。 这 类 故障 在 10 年 前 极为 普遍 ， 几 乎 每 个 HP-UX 用 户 都 会 遇 到 。HP- 
UX 在 进程 派生 的 时 候 ， 需 要 在 交换 空间 复制 一 份 进程 数 据 ， 由 于 交换 空间 的 不 足 ， 导 致 HP-UX 仅 仪 可 以 使 用 不 超过 交换 空间 的 内 存 空 间 ， 也 就 是 
说 ， 即 使 你 有 32GB 内 存 ， 如 果 交 换 空间 只 有 2GB， 那 也 只 能 使 用 2GB 的 进程 内 存 空 间 。 但 是 现在 ， 可 能 随 着 操作 系统 特性 的 变更 ， 这 类 故障 已 消 
AT. 


7.2 ”物理 内 存 和 虚拟 内 存 


CPU 是 Oracle 系 统 的 心脏 ， 是 Oracle 业 务 系统 最 为 昂贵 的 部 件 。 不 过 ， 物 理 内 存 应 该 才 是 Oracle 业 务 系统 运行 的 核心 部 件 ， 因 为 它 承 担 着 运行 
性 能 均衡 器 的 作用 。 内 存 连 接着 CPU 和 IO Subsystem 及 Network Subsystem， 是 CPU 和 IO Subsystem、CPU 和 Network Subsystem 之 间 的 润滑 
剂 。 内 存 为 CPU 提供 低级 的 缓存 ， 为 MO 提供 高 级 的 缓存 ， 进 而 使 CPU 和 IO 的 处 理 能 力 相 匹配 。 


虚拟 内 存 ， 也 可 以 称 之 为 逻辑 内 存 ， 为 应 用 程序 的 内 存 工 作 空间 。 虚 拟 内 存 提 供 了 极 大 的 柔韧 性 ， 简 化 了 小 内 存 环境 的 工作 ， 降 低 了 应 用 程序 
的 复杂 性 。 正 是 因为 虚拟 内 存 是 逻辑 存在 的 内 存 ， 是 配置 出 来 的 内 存 ， 所 以 在 实际 运行 中 人 存在 着 大 量 配 置 不 当 导 致 虚拟 内 存 运 行 效率 低下 的 案例 。 


虚拟 内 存 基 本 由 工作 空间 和 缓存 空间 构成 ， 工 作 空间 就 是 真实 的 物理 内 存 ， 而 缓存 空间 则 是 由 块 设备 构成 的 ， 包 括 磁 盘 或 固态 硬盘 等 块 设备 。 
依据 实现 机 制 的 不 同 ， 实 际 虚 拟 内 存 的 大 小 又 会 有 区 别 ， 通 常 是 工作 空间 和 缓存 空间 的 总 和 或 缓存 空间 的 大 小 。 


虚拟 内 存 管理 程序 将 不 断 老化 的 物理 内 存 中 的 值 缓存 到 交换 空间 中 ， 从 而 释放 物理 内 存 以 提供 更 多 的 空间 ( 见 图 7-1) 。 从 图 中 可 以 看 到 ， 只 
要 应 用 不 再 需要 存放 在 交换 空间 中 的 信息 ， 虚 拟 内 存 就 会 使 内 存 空 间 无 限 放 大 ， 同 时 不 会 影响 内 存 性 能 。 但 是 在 以 下 场景 下 ， 虚 拟 内 存 的 性 能 将 会 
下 降 : 


图 7-1 物理 内 存 和 虚拟 内 存 
需要 物理 内 存 的 时 候 ， 物 理 内 存 空间 不 足 ， 需 要 等 待 物理 内 存 缓存 信息 到 交换 空间 之 后 才 可 以 获得 物理 内 存 。 
当 应 用 程序 需要 内 存 中 数据 的 时 候 ， 发 现 数据 在 交换 空间 中 。 需 要 首先 把 信息 从 交换 空间 迁移 或 复制 到 物理 内 存 中 。 


在 上 面 这 两 种 情况 下 ， 内 存 的 速度 就 会 降低 为 磁盘 的 速度 ， 甚 至 更 差 。 


7.3 简单 的 虚拟 内 存 管 理 


虚拟 内 存 管理 一 般 采 用 分 页 的 方式 进行 ， 页 面 大 小 一 般 为 4KB， 也 可 以 是 其 他 尺寸 , 如 64KB、16MB 甚 至 16GB。 页 面 分 配 是 基于 整个 虚拟 内 
存 进行 分 页 的 ， 而 不 是 基于 物理 内 存 ( 见 图 7-2) 。 可 以 看 到 ， 一 个 页 面 可 能 在 真实 的 物理 内 存 中 ， 也 可 能 在 交换 空间 中 。 显 然 ， 在 不 同 的 地 方 ， 
其 访问 速度 差异 是 很 大 的 。 操 作 系 统 需 要 确定 一 种 算法 来 完成 物理 内 存 和 交换 空间 信息 的 迁移 ， 一 般 都 采用 LRU 算 法 来 完成 。 除 了 简单 的 LRU 算 法 
外 ， 还 可 以 基于 不 同 的 页 面 类 型 来 完成 更 好 的 虚拟 内 存 管理 调度 。 


74 虚拟 内 存 运行 性 能 的 衡量 


744 虚拟 内 存 运 行 性 能 


业务 进程 并 非 在 物理 内 存 中 运行 ， 而 是 在 虚拟 内 存 中 运行 ， 因 此 需要 衡量 的 是 虚拟 内 存 的 性 能 。 衡 量 虚 拟 内 存 的 运行 效率 主要 看 当 需 要 内 存 访 
间 时 访问 目标 是 否 在 物理 内 存 中 ， 其 次 查看 内 存 访问 的 搜索 效率 。 稀 量 虚拟 内 存 性 能 最 主要 的 指标 为 pageswapin 和 pageswapout。 


` pageswapin: 当 需 要 访问 信息 的 时 候 ， 该 信息 在 交换 空间 中 ， 业 务 进程 需要 等 待 信息 从 交换 空间 读 取 到 内 存 中 。 
` pageswapout: 当 需 要 内 存 自由 空间 的 时 候 ， 得 迁移 部 分 信息 到 交换 空间 中 以 释放 内 存 ， 业 务 进程 需要 等 待 信息 从 内 存 迁 移 到 交换 空间 。 
除了 pageswapin 和 pageswapout 指 标 之 外 ， 下 面 的 指标 也 用 来 辅助 衡量 虚拟 内 存 性 能 。 
free: 物理 内 存 自由 空间 列表 。 
- buffers: 物理 内 存 中 的 buffer 数 量 。 
' caches: 物理 内 存 中 的 cache 数 量 。 
- page pagein: 分 页 守护 进程 把 页 面 从 内 存 迁 移 到 交换 空间 。 
- page pageout: 分 页 守护 进程 把 页 面 从 交换 空间 迁移 到 内 存 。 
vmstat 命 令 和 sar 命 令 都 可 以 用 来 反映 虚拟 内 存 的 运行 情况 。 图 7-16 是 vmstat 命 令 的 实时 输出 信息 。 
[root@test 4603]# vmstat 2 5 
memory i system 


free buff cache i in cs us sy id wa st 
8 459056 118640 512696 625 7 86 


8 459040 118640 512696 61 0 99 
8 459040 118648 512688 60 1 99 
8 459040 118648 512696 58 9 99 
8 459040 118648 512696 56 1 99 


图 7-16 vmstat 命令 的 实时 输出 信息 
中 ，swap 部 分 的 si 和 so 反映 了 pageswapin 和 pageswapout 的 情况 。memory 部 分 反映 了 内 存在 物理 内 存 和 交换 空间 之 间 的 分 布 情况 


(1 CPU) 


10/15/2014 


sar-B 命 令 从 另 一 个 角度 实时 地 反映 了 虚拟 内 存 的 活动 主要 是 分 页 守护 进程 ， 如 图 7-17 所 示 。 
_x86 64 
fault/s Np Ps didi Y" iki M 


[root@test 4603]# sar -B 2 5 
Linux 2.6.39-400.17.1.e16uek.x86 64 (test) 


05: :03: 18 AM nia i iip 
0.0 30.6 


7.5 ”虚拟 内 存 资 源 的 主要 衡量 指标 


7.5.1 


下 面 介 绍 虚 拟 内 存 的 主要 性 能 衡量 指标 。 


“ page swap in: 业务 进程 需要 等 待 从 交换 空间 换 入 物理 内 存 的 页 
个 指标 没有 问题 ， 就 表示 虚拟 内 存 至 少 当 前 运行 是 没有 问题 的 。 
页 面 数 量 。 该 指标 和 page swap in 一 起 构成 虚拟 内 存 的 核心 性 能 指标 。 


业务 进程 需要 等 待 从 物理 内 存 换 入 交换 空间 的 页 
问题 的 。 
F 护 进程 的 活跃 程度 。 


page swap out: 
和 运行 


个 指标 没有 问题 ， 就 表示 虚拟 内 存 至 少 当前 
程 从 交换 空间 换 入 物理 内 存 的 页 面 数量 
该 指标 和 page page in 一 起 构成 了 分 


虚拟 内 存 的 主要 性 能 衡量 指标 
kE. 该 指标 和 page swap out 一 起 构成 虚拟 内 存 的 核心 性 能 指标 。 只 要 这 两 


云 行 是 没有 问题 
该 指标 和 page page out 一 起 构成 了 分 
守护 进程 的 活跃 程度 。 


只 要 这 两 


ZN 


该 指标 要 保持 相对 平缓 状态 ， 剧 烈 变化 表示 内 存 使 用 极 不 规则 ， 该 值 过 小 意味 着 极 有 可 能 在 未 来 会 引 


- page page in: 分 页 
- page page out: 分 页 守护 进程 从 物理 内 存 换 入 交换 空间 的 页 面 数量 。 
: memfree: 物理 内 存 的 空闲 列表 大 状态 ， 
起 page swap out 和 page swap in， 需 要 使 之 保持 充分 的 大 小 从 而 使 未 来 虚拟 内 存 具 有 可 伸缩 性 
- buffers+caches: 表示 非 计算 分 页 在 物理 内 存 中 占用 页 面 的 数量 ， 在 free 有 限 的 系统 中 ， 该 值 和 used 相 比 过 大 意味 着 可 能 文件 系统 缓存 配置 存 
在 问题 ， 或 者 分 页 守护 进程 的 活跃 程度 不 够 
swap cache 利 用 率 : 交换 空间 的 使 用 率 。 该 值 起 过 50% 甚 至 30% 往 往 意味 着 交换 空间 配置 不 够 ， 导 致 分 页 守护 进程 效率 下 降 。 该 值 达 到 80% 以 
上 则 很 容易 在 极限 情况 下 引起 业务 系统 全 面瘫 痰 。 
` Nr ETHS 
7.6_ 几 个 虚拟 内 存 资源 常见 问题 的 讨论 
间 还 是 很 少 
是 很 多 人 会 提出 的 问题 ， 其 实 原因 很 简单 ， 内 存 最 
是 会 对 内 存 的 需求 采用 贪 


7.6.1 有 128GB 的 内 存 ， 为 什么 自由 空 
虽然 业务 系统 配置 的 内 存 很 多 ， 但 是 系统 总 体 的 内 存 自由 空间 列表 却 总 是 很 少 
比如 磁盘 、 网 卡 等 。 操 作 系 统 为 了 


性 能 比较 差 的 设备 进行 缓存 加 速 ， 
它 就 会 使 用 ， 直 到 吃 光 内 存 或 到 达 内 存 控制 线 为 止 


只 要 有 内 存 ， 


=N 


主要 的 作用 就 是 给 
林 模 式 运行 ， 也 就 是 说 


， 为 什么 ? 这 
运行 效率 ， 充 分 利用 资源 ， 总 


我 们 来 做 一 个 简单 的 测试 ， 如 图 7-35 所 示 。 


[root@test proc]# free -m 
total used free shared buffers 

Mem: 1458 322 1136 0 1 
-/* buffers/cache: 245 1212 
Swap: 1023 0 1023 
[root@test proc]# lp-5 
[root@test proc]# while [ $lp -gt 0 ] 
» do 

dd if=/dev/zero of-/tmp/d$lp.log bs-10240008 count-100 

lp= expr $lp - 1 

sleep 1 
> done 
10040 records in 
10040 records out 
102400000 bytes (102 MB) copied, 0.327995 s, 312 MB/s 
10040 records in 
10040 records out 
102400000 bytes (102 MB) copied, 0.415694 s, 246 MB/s 
10040 records in 
100«0 records out 
102400000 bytes (102 MB) copied, 0.263934 s, 388 MB/s 
10040 records in 
10040 records out 
102400000 bytes (102 MB) copied, 0.266499 s, 384 MB/s 
10040 records in 
10040 records out 
102400000 bytes (102 MB) copied, 0.269879 s, 379 MB/s 
[root@test proc] free -m 

total used free shared buffers 

Mem: 1458 827 631 0 3 
-/* buffers/cache: 259 1199 
Swap: 1023 0 1023 


图 7-35 ”测试 代码 


从 图 7-35 可 以 看 到 ， 就 是 简单 的 dd 复制 命令 ， 就 使 free 从 1136MB 降 到 了 631MB， 同 时 在 cached 中 增加 了 近 500MB。 事 实 上 ， 我 们 在 计算 
Linux 系 统 自由 空间 的 时 候 不 能 仅 查 看 free 部 分 ， 而 应 该 是 free+buffers+cached。 


7.7 ”虚拟 内 存 资 源 优化 的 目标 和 道路 


7.7.1 虚拟 内 存 资 源 问题 的 场景 和 优化 道路 

虚拟 内 存 不 同 于 CPU 资源 ， 其 真正 的 性 能 是 配置 出 来 的 。 不 管 物理 内 存 大 小 如 何 ， 只 要 配置 适当 ， 就 不 会 存在 虚拟 内 存 的 运行 效率 问题 。 从 这 
点 来 看 ， 虚 拟 内 存 又 是 最 容易 管理 的 。 

虚拟 内 存 的 运行 效率 主要 基于 以 下 几 个 方面 来 考虑 。 


- 运行 进程 避免 page swapin 和 page swapout 的 发 生 。 


- 合理 配置 避免 未 来 发 生 page swapin 和 page swapout。 
“ 业务 程序 合理 分 配 内 存 ， 使 其 始终 控制 在 安全 的 物理 内 存 使 用 范围 。 
:充分 利用 内 存 资源 ， 使 业务 程序 高 效 运行 。 


“ 合理 调度 业务 程序 ， 避 免 过 度 同 时 使 用 内 存 。 


7.8 虚拟 内 存 资 源 优化 案例 


1. 从 AWR 报 告 断言 虚拟 内 存 资源 存在 大 量 交 换 


某 工商 局 的 业务 运行 缓慢 ， 从 AWR 报 告 看 似乎 一 切 处 于 正常 状态 ， 无 论 是 CPU 运行 还 是 等 待 事件 冲突 都 没有 太 大 问题 。 简 单 计算 频繁 运行 的 
SQL 语句 的 buffer gets 响 应 时 间 ， 发 现在 索引 访问 的 情况 下 ， 每 次 buffer get 访 问 都 超过 了 100hs， 感 觉 内 存 访问 效率 不 高 (正常 情况 下 是 几 十 微 
秒 ， 甚 至 几 微 秒 ) 。 让 同事 进一步 检查 用 户 的 操作 系统 状况 ， 果 然 发 现 比较 高 的 虚拟 内 存 交 换 现象 ， 降 低 SGA 区 之 后 性 能 恢复 正常 。 


2. 大 文件 拷贝 导致 业务 系统 性 能 快速 变 差 


某 运 营 商 业务 系统 在 某 个 时 间 点 突然 变 差 ， 检 查 操 作 系统 发 现 有 大 量 的 虚拟 内 存 交换 现象 。 检 查 消耗 内 存 的 Top 进 程序 列 ， 除 了 一 个 cp 程序 之 
外 ， 其 他 表现 一 切 正常 。cp 命 令 正在 执行 一 个 六 十 多 GB 的 大 文件 拷贝 操作 ， 消 耗 了 大 量 的 内 存 。 中 断 cp 操 作 之 后 业务 恢复 正常 。 


大 文件 拷贝 导致 业务 系统 性 能 变 差 的 主要 原因 在 于 操作 系统 分 页 策略 参数 配置 不 当 ，AIX 的 vmo 参 数 采 用 的 是 默认 值 。 修 正 vmo 配 置 之 后 ， 再 
次 启动 大 文件 拷贝 操作 ， 业 务 系统 可 以 无 干扰 地 运行 。 


3.rman 备 份 导致 系统 性 能 下 降 


某 社保 客户 反映 系统 整体 性 能 严重 下 降 ， 原 本 一 秒 钟 内 完成 的 业务 会 延迟 至 5~6 秒 ， 主 机 telnet 登 录 明显 延迟 ， 显 然 存 在 虚拟 内 存 或 其 他 相关 
资源 不 足 的 问题 。Topas 的 结果 如 图 7-42 所 示 。 


从 Topas 数 据 可 以 看 出 ，hdisk0 和 hdisk1 的 busy 分 别 为 100% 与 99%， 交 换 使 用 为 65%， 内 存 的 comp 为 29，noncomp 为 71。 同 时 ,vmstat 
显示 出 系统 存在 大 量 的 交换 。 检 查 数据 库 发 现 ， 其 中 RMAN backup & recovery I/O 等 待 事件 严重 ,检查 发 现 客户 正在 进行 磁带 增 量 备份 。 显 然 
是 RMAN 备 份 导 致 了 虚拟 内 存 资源 不 足 ， 而 导致 RMAN 使 用 巨 量 内 存 的 原因 就 在 于 虚拟 内 存 参 数 配置 不 当 ， 使 用 了 太 多 的 内 存 用 于 文件 系统 缓存 。 
调整 虚拟 内 存 参 数 : 


root@dancdb02: /#vmo-p-o minperm%=10 
Setting minperm%to 10in nextboot file 
Setting minperm%to 10 

root@dancdb02: /#vmo-p-o maxclient%=10 
Setting maxclient%to 10in nextboot file 
Setting maxclient%to 10 

root@dancdb02: /#vmo-p-o maxperm%=15 
Setting maxperm%to 15in nextboot file 


Setting maxperm%to 15 


Topas Monitor for host: 
Tue Jan 6 15:10:18 2015 


AIXTEST 
Interval: 


CPU User$ Kern$ Wait% Idle% 


ALL 1.0 


Network KBPS 
63.7 


Total 


Disk 
hdisk22 
hdisk2 
hdisk0 
hdiski 
hdisk3 
cd0 
hdisk6 


FileSystem 
Total 


Name 
aioserver 
aioserver 


6.7 46.4 45.9 
I-Pack O-Pack 


1026.0 3.0 


KB-In KB-Out 
60.5 3.1 
KBPS KB-Writ 
26.5K 
18.K 

3.5K 


TPS KB-Read 


KBPS TPS KB-Read KB-Writ 
2.3K 712.5 2.3K 16.8 
SerV2 
Cliv2 

SerV3 

Cliv3 


PID 
3271960 
419432 


CPU%  PgSp Owner 
4.0 0.8 root 
4.0 0.2 root 


图 7-42 Topas 数 据 


EVENTS/QUEUES 


Cswitch 
Syscall 
Reads 
Writes 
Forks 
Execs 
Runqueue 


Waitqueue 


PAGING 
Faults 
Steals 
PgspIn 
PgspOut 
PageIn 
PageOut 
Sios 


0 Press: 
0 "q"-quit 


FILE/TTY 
Readch 
Writech 
216 Rawin 

37 Ttyout 

1 Igets 

0 Namei 
0.5 Dirblk 
72.0 


5312 
1805 


MEMORY 
Real,MB 
1369 % Comp 

12856 $€ Noncomp 
3 % Client 
858 
5898 
7641 
13309 


Size,MB 
% Used 
$ Free 


NFS (calls/sec) 


0 WPAR Activ 
0 WPAR Total 
"h"-help 


30.1M 
26.5M 
0 
389 
0 
177 
0 


16384 
31 
68 
68 


PAGING SPACE 


16384 
73 
27 


0 
0 


AIX 系 统 内 存 参数 调整 完成 后 ，noncomp 的 值 立即 降 到 了 9， 而 vmstat 的 交换 也 在 逐渐 减少 ， 再 进行 rman 物理 备份 测试 ， 系 统 和 应 用 已 经 基 
本 上 没有 任何 影响 ， 业 务 访问 正常 。 


4 调整 HugePage 使 得 业务 系统 性 能 大 幅度 提高 


某 城 商行 管理 系统 采用 X86 架构 ， 操 作 系 统 内 存 为 512GB， 在 上 线 初 期 我 们 采用 TPCC 进 行 压力 测试 ， 整 体 测试 效果 并 不 理想 。 表 7-1 所 示 的 为 


具体 的 测试 参数 。 


表 7-1 


2 HH 
WERTE 
SGA TARGET 

Warehouse 

虚拟 用 户 数 

transaction per use 


TPCC 并 发 数 


目标 系统 的 基本 测试 配置 


10 000 000 
200 


以 上 参数 在 正常 的 估算 下 ， 每 分 钟 事务 数 应 该 达到 10 万 左右 才 算 勉强 达到 基本 的 性 能 数据 ， 但 是 在 真实 的 测试 环境 下 我 们 发 现 每 分 钟 的 事务 数 
在 8 万 左右 ， 而 且 CPU 被 系统 大 量 消耗 ， 内 存 资源 也 被 大 量 消耗 ， 但 是 整体 的 性 能 没有 得 到 明显 的 提升 。 图 7-43~ 图 7-45 为 压力 测试 过 程 中 的 结 


果 。 


E HET Tdi 


Benchmark (^. Script Editor - L | Transaction Counter 0 


- Oracle 
y TPC-C 

b Schema Build 

v v» Driver Script 
> Options 
; Load 

- Üş Virtual User 
«4 Options 


b {> Autopilot 
~ Ø Transactions 
3 Options 


— EE o UE o UM a 
cococococococoodo 


... 1 events added 
Main console display active (Tc18.6.0 / Tk8. 6.0) 
e » nn in config.xml is well-formed, applying variables 


图 7-43 TPCC 压 力 测试 图 


Ye Wait% alel 
93. .0  0.5|UUUsssss555555S5555555555555555555555555555555555» 
5|UUssssssSsss5555555555555555555555555555555555555» 
O0|UUUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS» 
.O[uuussssssssssssssSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS» 
. OJ UUUUUUUUSS555555555555555555555555555555555555555» 
0|UUUS555555555555555555555555555555555555555555555» 
5|UUUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS» 
. S|UUUUUUUUSS555555555555555555555555555555555555555» 
.O| UUUUUUUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS» 


boooowowweoo 
2222p222 


DONGwmmW 


0 
0 
0 
.0 
0 
0 
0 


图 7-44 CPU 消耗 图 


On—1L4 1———— — — — — — — ——MHostnamesmtsdb1—— —— ——Refreshe 2secs 


RAM High Low Swa Page Size=4 KB 
Total MB -0.0 -0.0 131072.0 
Free MB -0.0 -0.0 131072.0 
Free Percent 0.2% 100.0% 100.0% 100.0% 


MB MB 
Cacheds194288. 0 Actives 32262.6 
Bufferss 268.1 Swapcacheds 0.0 Inactive =165098.0 
Dirty = 68.4 writeback = 0.0 Mapped = 554.0 
Slab = 6067.9 Commit 9853.7 PageTables» — 134.2 


图 7-45 内存 消耗 图 


通过 优化 Linux 的 内 存 页 ， 将 传统 的 4KB 内 存 页 改 成 HugePages (内 存 大 页 ) ， 再 次 进行 压力 测试 ， 此 时 ， 整 体 的 性 能 得 到 大 幅 提升 ， 每 分 钟 
的 事务 数 达到 了 22 万 左右 ，CPU 空 闲 率 良 好 。 


从 图 7-46 到 图 7-47 可 以 看 到 ， 将 普通 的 Linux 4K 内 存 页 换 成 HugerPages 后 ， 整 体 的 性 能 得 到 大 幅度 提升 ， 而 且 从 目前 的 压力 测试 上 看 ， 压 力 
可 以 继续 往 上 ， 并 没有 达到 系统 的 压力 极限 。 
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图 7-47 ”CPU 消耗 图 
5.Oracle SGA 区 域 配置 不 当 导 致 运行 性 能 不 佳 


某 工商 局 业务 系统 长 期 以 来 性 能 不 佳 ，8CPU/16GB 内 存 的 配置 ， 从 真实 业务 负载 以 及 与 其 他 工商 局 比较 来 看 ， 应 该 获得 很 好 的 性 能 。 查 看 
AWR 报 告 ， 发 现 SGA 区 域 仅仅 配置 了 100MB，buffer cache 的 命中 率 为 可 怜 的 40%。 简 单 增加 SGA 区 域 到 6GB， 所 有 性 能 问题 消失 。 


第 8 章 资源 供给 SA: |/O 子 系统 


8.1 简单 案例 分 享 


在 某 运 营 商 的 OCS 实时 计 费 系统 中 ， 实 时 计 费 的 效率 不 够 快 ， 磁 盘 /O 的 使 用 率 为 100%。 简 单 咨询 其 流程 结构 : 11 个 并 行 查询 进程 的 结果 送 
到 一 个 处 理 中 心 进行 处 理 。 开 发 商 分 析 磁 盘 /O 的 处 理 能 力 不 足 ， 处 理 中 心 却 有 富余 。 笔 者 问 如 果 查 询 数 据 每 秒 返 回 100MB 是 否 可 以 达到 处 理 效 
率 ， 回 答 是 肯定 的 。 因 此 ， 笔 者 提供 了 一 种 非常 简单 的 处 理 措施 ， 即 改变 并 行 查询 为 串 行 。 在 开发 商 经 过 简单 的 修正 之 后 ，MO 子 系统 获得 足够 的 
数据 ， 使 处 理 中 心 的 效率 无 法 支撑 。 


思考 一 下 ， 为 什么 在 本 案例 的 处 理 中 ， 笔 者 甚至 都 没有 登录 系统 ， 登 录 数 据 库 ， 当 然 也 没有 看 AWR。 要 知道 ，MO 子 系统 的 资源 不 是 无 限 的 ， 
磁盘 只 是 一 个 机 械 设 备 ， 当 超过 其 负载 的 时 候 ， 其 响应 时 间 就 会 大 幅 增加 。11 个 并 行 查询 将 产生 1GB/s 的 读 / 写 要 求 ， 不 管 是 HBA 卡 、SAN 
Switch， 还 是 EMC DMX4000 都 无 法 支撑 如 此 巨大 的 数据 库 知 吐 要 求 ， 可 以 想象 ， 这 种 情况 下 MO 子 系统 自然 会 被 塞 死 ， 响 应 时 间 也 就 大 幅 延迟 
T. 
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8.2 1/O 子 系统 和 构成 


从 性 能 优化 的 角度 来 看 ，MO 子 系统 可 能 是 Oracle 业 务 系统 最 为 重要 的 部 件 ， 原 因 非 常 简单 : MO 子 系统 是 Oracle 业 务 系统 中 涉及 的 最 慢 速 的 部 
件 ， 所 有 快速 流动 的 流程 都 会 在 这 里 被 堵塞 。 在 主机 系统 中 为 什么 需要 内 存 ” 就 是 因为 磁盘 系统 的 速度 太 慢 ， 完 全 无 法 匹配 CPU 的 处 理 速 度 ， 所 以 
需要 内 存 系统 在 中 间 进 行 缓存 处 理 。 如 果 磁盘 系统 的 速度 足够 快 ， 内 存 就 没有 必要 存在 了 。 


我 们 来 看 看 CPU、 内 存 和 磁盘 系统 的 延迟 比较 ， 如 表 8-1 所 示 。 


表 8-1 不 同 的 I/O 系 统 设备 的 性 能 差异 


W 5 SUASTTE "CENE: 
ET wem | — = 
Filesystem 依赖 实现 
LVM 依赖 实现 
Ethernet Switch 100us 
Disk 100 6 ~ 10ms 


可 以 看 到 ，CPU、 内 存 的 低 延 迟 和 IO 子 系统 的 高 延迟 存在 巨大 差异 。 如 何 跨 越 CPU/ 内 存 和 机 械 磁盘 之 间 的 巨大 性 能 差异 ， 是 业务 系统 设计 者 
和 开发 者 乃至 DBA 等 性 能 优化 者 的 主要 挑战 方向 。 基 本 而 言 ， 缺 乏 优 化 的 业务 系统 总 是 趋向 于 I/O 尊 贷 的 ， 解 决 了 I/O 问 题 就 解决 了 全 部 或 绝 大 部 分 
的 业务 系统 性 能 问题 。 


在 内 存 和 磁盘 系统 之 间 存 在 着 长 长 的 链 路 ， 包 括 软件 和 硬件 。 就 现在 最 流行 的 SAN 存 储 网 络 而 言 ， 主 要 包含 以 下 部 件 。 
. 卷 管理 器 和 文件 系统 : 通过 卷 管理 器 和 文件 系统 可 以 方便 有 效 地 管理 磁盘 系统 等 硬件 。 

- HBA 和 SAN 交 换 机 : HBA 卡 和 SAN 交 换 机 构成 FC 网 络 ， 连 接 主机 和 存储 系统 。 

“ 磁盘 系统 : 从 性 能 角度 看 ， 磁 盘 系 统 主要 包含 控制 器 、Raid、Cache 和 磁盘 。 

除了 SAN 网 络 之 外 ， 还 存在 其 他 不 同 结构 的 存储 系统 ， 比 如 DAS、NAS、iSCSI、FCoE、1B SAN 等 。 


在 CPU 和 内 存 快 速 发 展 的 历史 中 ， 磁 盘 一 直 发 展 缓慢 ， 除 了 容量 在 不 断 增长 之 外 ， 性 能 几乎 没有 发 生 本 质 性 变化 。 一 直到 近 几 年 开始 普及 的 固 
态 硬盘 ， 特 别 是 PCle SSD 的 出 现 给 磁盘 带 来 了 本 质 性 的 变更 ， 连 带 着 存储 系统 网 络 架构 也 发 生 了 很 大 变化 。 比 如 以 前 一 直 不 温 不 火 的 1B 网 络 随 着 
PCle 的 兴起 而 迅速 变 得 流行 。 


8.3 ” 卷 管理 器 和 文件 系统 


8.3.1 SEIER 


卷 管理 器 (LVM) 和 文件 系统 是 磁盘 系统 的 基本 管理 工具 。 几 乎 每 个 操作 系统 厂商 都 提供 了 自己 的 卷 管理 器 ， 也 包括 Linux 从 简单 的 文件 系统 
走向 了 LVM。 对 于 Oracle 业 务 系统 ， 逐 渐 开 始 走向 主流 的 AsSM 从 本 质 上 来 说 就 是 一 个 卷 管理 器 ， 只 不 过 针对 Oracle 数 据 库 做 了 特别 优化 和 自动 化 
处 理 ， 使 用 户 使 用 起 来 更 加 简单 。 


1. 卷 管理 器 的 基本 体系 结构 


大 部 分 卷 管理 器 依赖 于 存储 层 提供 物理 磁盘 的 划分 和 管理 ， 比 如 IBM LVM, HP LVM, Linux LVM Oracle ASM。 但 也 有 部 分 卷 管理 器 提供 
了 物理 磁盘 的 划分 和 管理 功能 ， 比 如 VxVM。 


下 面 借用 AIX LVM 和 VxVM 的 一 些 概念 来 描述 卷 管理 器 。 
“ pDisk: 存储 系统 提供 给 主机 的 磁盘 。 
“ hDisk: LVM 映 射出 来 的 对 应 pDisk 的 虚拟 磁盘 设备 ，VxVM 表 述 为 vrmdisk。 
DiskGroup: 磁盘 组 ，AIX 并 没有 磁盘 组 的 概念 。 一 堆 hDisk 构 成 一 个 磁盘 组 。 
VG: 卷 组 ， 大 部 分 LVM 的 卷 组 都 直接 建立 在 hDisk 之 上 ， 包 括 Oracle ASM。 大 部 分 卷 管理 器 支持 卷 级 别 镜像 和 条 带 化 。 
"LV: 在 卷 组 之 上 建立 的 块 设备 ， 可 以 在 LV 层面 做 镜像 或 者 条 带 化 。 
PP: LV 在 某 个 特定 物理 磁盘 上 的 最 小 分 配 单元 。 
“LP: LV 的 最 小 逻辑 分 配 单元 ，LP=NXPP，N 为 镜像 层 数 。 
` Filesystem: 文件 系统 ， 文 件 系 统 在 LVM 中 是 一 种 特殊 的 LV。 
不 过 ， 因 为 在 VxVM 中 存在 物理 磁盘 划分 功能 ， 因 此 会 比 一 般 的 LVM 多 几 个 层次 ， 如 下 。 
Subdisk: VxVM 支 持 对 物理 磁盘 的 再 次 划分 ， 一 个 物理 磁盘 可 以 分 成 N 个 Subdisk，Subdisk 是 相对 于 其 他 LVM 的 pDisk， 也 就 是 物理 磁盘 。 
Plex: 一 个 或 者 多 个 Subdisk 构 成 一 个 Plex，Plex 就 相当 于 其 他 LVM 的 hDisk。VxVM 的 卷 建 立 在 Plex 之 上 ，Raid 能 力 当 然 也 建立 在 Plex 上 。 
VxVM 除 多 了 物理 磁盘 划分 之 外 ， 与 其 他 LVM 并 没有 本 质 上 的 区 别 ，VxVM 只 是 多 做 了 存储 系统 的 物理 磁盘 划分 工作 。 


图 8-1 是 VxVM 卷 管理 器 的 一 简单 层次 图 。 


2.0racle ASM 卷 管理 器 

Oracle ASM 是 一 种 特殊 的 卷 管理 器 ， 考 虑 到 其 在 Oracle 数 据 库 中 的 绝对 主流 性 质 ， 有 必要 在 这 里 简单 介绍 一 下 。 详 细 介绍 可 以 参见 后 续 组 件 
部 分 的 ASM 章 节 。 

Oracle ASM 和 一 般 的 LVM 不 同 ， 它 关心 的 是 操作 系统 提供 的 对 象 。 而 其 他 LVM 关 心 的 是 存储 系统 提供 的 对 象 ， 也 就 是 说 ，Oracle ASM 作 用 
在 更 上 层 ， 这 也 就 意味 着 Oracle ASM 可 以 和 其 他 任何 LVM 配 合 完成 工作 。 
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图 8-1 VxVM 卷 管理 器 层次 图 


Oracle DiskGroup 可 以 接受 物理 磁盘 、 罗 辑 卷 、 文 件 甚至 NFS 文 件 来 构成 其 物理 来 源 。 用 户 只 要 关心 把 哪些 设备 纳入 DiskGroup， 其 他 交 给 
Oracle 来 自动 管理 就 行 。 


Oracle ASM 的 一 些 主要 概念 如 下 。 
- ASM Disk: 物理 磁 瘟 ， 文 件 或 NFS 文 件 都 可 以 作为 ASM Disk 存 在 。 
: ASM DiskGroup: 由 一 堆 ASM Disk 构 成 。 
: ASM FailGroup: 故障 组 ， 完 成 镜像 工作 。 
: ASM File: 由 Oracle 自 动 地 在 ASM DiskGroup 上 生成 的 文件 (如 数据 文件 、 在 线 日 志文 件 等 ) ， 相 当 于 卷 管理 器 的 LV。 
ASM AU: ASM 物 理 磁盘 的 一 次 分 配 空间 大 小 。 


- ASM Stripesize: ASM 文 件 的 条 带 大 小 。 


: ASM Stripewidth: ASM 文 件 的 条 带宽 度 。 


需要 注意 的 一 点 是 ，Oracle 的 条 带 化 不 作用 在 ASM Disk 上 ， 而 是 作用 在 ASM File 上 。 


8.4 ” HBA、SAN 交 换 机 及 其 他 存储 系统 链 路 通道 


8.4.1 HBA 和 SAN 


SAN 存 储 网 络 是 目前 高 端 数据 中 心 的 主流 网 络 ， 可 通过 HBA 和 SAN 交 换 机 把 主机 和 存储 系统 联系 起 来 构成 这 样 一 个 网 络 。SAN 存 储 网 络 的 带宽 
从 原先 的 1Gbit 和 2Gbit 演 变 到 现在 的 4Gbit 和 8Gbit。 由 于 每 块 HBA 卡 基本 具有 超过 10 万 iops 的 吞吐 能 力 ， 因 此 从 iops 角 度 来 说 ，HBA 卡 和 SAN 交 
换 机 存在 的 主要 问题 在 于 带宽 的 不 足 。 从 内 存 最 低 3.2GB 的 带宽 一 下 到 HBA 卡 的 200MB、400MB 或 800MB 的 带宽 ， 下 降 还 是 比较 迅速 的 。 为 了 支 


持 CPU 和 内 存 高 效 处 理 能 力 ， 从 性 能 角度 考虑 需要 为 每 台 主 机 配置 超过 1 块 HBA 以 支持 性 能 和 可 靠 性 。 


在 HBA 和 SAN 固 定 的 FC 结 构 下 ， 影 响 性 能 的 主要 因素 表现 为 HBA 卡 的 队列 深度 。 队 列 深度 会 极 大 地 影响 HBA 的 iops， 并 使 HBA 卡 充分 发 挥 其 
带宽 处 理 效率 。 遗 憾 的 是 ， 不 同 的 HBA 设 备 其 HBA 卡 的 队列 深度 也 不 尽 相 同 。 总 之 ， 你 觉得 没有 充分 发 挥 存储 系统 的 性 能 ， 那 么 加 大 队列 深度 ， 你 
觉得 存储 系统 已 经 过 载运 行 ， 那 就 降低 队列 深度 。 

如 何 设置 HBA 的 队列 深度 ”不 同 的 HBA 设 备 有 不 同 的 方式 ， 大 家 可 以 依据 自己 的 HBA 卡 设备 查找 对 应 文档 修改 。 主 要 的 HBA 卡 供应 商 为 


Qlogic 和 Emulex。 


图 8-6 中 的 设置 源 于 互联 网 相关 文档 ， 笔 者 未 经 过 测试 和 验证 。 


e For Qlogic: 
options qla2xxx gl2xmaxqdepth-«value» 


e For Emulex: 
options lpfc lpfc_lun_queue_depth=<value> lpfc_hba_queue_depth=<value> 


图 8-6 QlogcfeEmulex HBA 的 列队 深度 设置 


图 8-7 是 SAN 存 储 网 络 的 简单 结构 。 
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图 8-7 ”SAN 存储 网 络 的 简单 结构 


HBA 卡 同样 会 遵循 图 8-8 所 示 的 吞吐 量变 化 曲线 。 
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图 8-8 吞吐 量 和 响应 时 间 关 系 图 


8.5 ”磁盘 和 磁盘 阵列 


Oracle 数 据 库 的 所 有 数据 最 终 会 存储 在 磁盘 上 ， 当 然 最 终 访问 也 会 在 磁盘 上 。 一 直 以 来 ， 磁 盘 的 发 展 速 度 都 是 远 远 落 后 于 CPU 和 内 存 的 ， 磁 盘 
和 内 存 之 间 的 差距 在 不 断 加 大 。 如 何 优化 磁盘 访问 的 性 能 一 直 是 Oracle 数 据 库 设计 和 优化 的 最 核心 课题 。 


8.6 Raid 和 LUN 


单 块 磁盘 显然 无 法 提供 可 靠 性 ， 也 无 法 提供 足够 的 性 能 。 通 过 Raid 的 支持 ， 磁 盘 阵列 就 能 提供 可 靠 性 和 性 能 的 扩展 了 。 
Raid 提 供 的 主要 价值 包括 以 下 几 方 面 。 
: 通过 并 行 读 / 写 米 增 加 磁盘 系统 的 吞吐 量 ， 并 提高 总 体 运 行 性 能 。 
通过 宛 余 来 提供 磁盘 系统 的 可 靠 性 。 


主要 的 Raid 方 式 有 Raid 0、Raid 1, Raid 5, Raid 0+1、Raid 1+0， 当 然 还 有 其 他 很 多 种 的 Raid 方 式 。 


1.Raid 0 

多 个 磁盘 形成 一 个 大 磁盘 ， 数 据 均 匀 地 分 散在 不 同 的 磁盘 上 ， 也 就 是 俗称 的 条 带 化 〈 见 图 8-10) , Raid 0 没有 任何 可 靠 性 保证 ， 但 是 提供 了 完 
全 并 行 读 / 写 访问 能 力 ， 可 以 充分 利用 每 个 磁盘 的 能 力 ， 具 有 最 好 的 性 能 和 最 差 的 可 靠 性 ， 一 般 仪 会 作用 在 某 些 | 临时 处 理 设备 上 。 
2.Raid 1 


Raid 1 简单 来 说 就 是 镜像 ， 在 一 组 N 个 磁盘 中 ， 每 两 个 磁盘 相互 做 镜像 ( 见 图 8-11) 。Raid 1 具有 很 高 的 可 用 性 ， 只 有 镜像 组 的 两 块 磁盘 都 损 
坏 才 会 丢失 数据 。 镜 像 组 也 提供 了 很 好 的 性 能 ， 具 有 很 好 的 并 发 性 读 取 能 力 ， 在 写 性 能 方面 优 于 并 行 写 或 者 AIO 的 作用 ， 虽 然 需要 同时 写 两 块 磁 
盘 ， 但 写 性 能 只 是 略微 降低 。 


Raid 0 


Disk 0 Disk 1 


图 8-10 Raid 0 的 数据 分 布 


Disk Disk 1 


图 8-11 Raid1 的 数据 分 布 


3.Raid 0+1 


Raid 0+1 是 Raid 0 和 Raid 1 的 混合 ， 为 了 使 高 性 能 的 Raid 0 有 可 靠 性 保证 ， 在 Raid 0 的 基础 上 混合 Raid 1， 使 之 兼顾 可 靠 性 和 性 能 ( 见 图 8- 


12) 。 从 其 实现 机 制 来 看 ， 显 然 其 只 针对 Raid 0 进行 了 简单 的 可 靠 性 增强 ， 两 组 磁盘 中 只 要 一 块 磁盘 发 生 故 障 ， 则 该 组 磁盘 将 继续 工作 ， 如 果 另 一 
组 磁盘 也 有 一 块 发 生 故 障 ， 则 整个 Raid 0+ 1 磁盘 组 将 停止 工作 。 


4.Raid 1+0 


Raid 1+0 同 Raid 0+1 一 样 ， 也 是 不 同 Raid 的 混合 ，Raid 1+0 是 为 了 增加 Raid 1 的 带宽 处 理 能 力 ， 在 Raid 1 的 基础 上 增加 了 Raid 0， 以 增加 并 
行 度 和 性 能 ( 见 图 8-13) 。 从 实践 来 看 ，Raid 1+0 是 极为 理想 的 Raid 解 决 方案 ， 特 别 是 在 存储 容量 价格 不 断 下 降 的 今天 。Raid 1+ 0 不 同 于 Raid 
0+1， 仅 当 相 互 镜像 的 磁盘 都 发 生 故 障 时 才 会 停止 工作 ， 其 可 靠 性 要 远 远大 于 Raid 0+1， 性 能 也 高 于 Raid 0+1， 提 供 了 更 高 的 并 发 性 。 
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图 8-12 Raid 0+1 的 数据 分 布 


Raid 1+0 
Raid 0 
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5.Raid 5 


Raid 5 是 一 种 兼顾 成 本 、 性 能 和 可 靠 性 的 解决 方案 ， 它 通过 类 似 于 Raid 0 的 条 带 化 来 增加 性 能 ， 通 过 校 验 位 来 提供 可 以 媲美 于 Raid 1 的 可 靠 
性 ， 同 时 大 幅 降低 了 存储 成 本 ( 见 图 8-14) 。Raid 5 是 一 种 广泛 使 用 的 Raid 方 式 ， 甚 至 相 比 Raid 1 和 Raid 1+0 更 加 流行 。 虽 然 如 此 ， 从 Oracle 观 
点 出 发 ， 只 要 你 可 以 承受 Raid 1+0， 就 采用 Raid 1+0， 而 不 要 采用 Raid 5。 
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图 8-14 Raid 5 的 数据 分 布 


Raid 5 提供 了 杰出 的 读 性 能 ,但 随机 写 性 能 非常 糟糕 ， 所 以 Raid 5 往往 需要 大 容量 的 Cache 支 持 。 大 容量 的 Cache 价 格 往往 会 导致 Raid 5 系统 
总 体 并 不 会 比 Raid 1+0 系 统 性 价 比 更 高 ， 而 Raid 5 的 制约 性 明显 强 于 Raid 1+ 0。 大 部 分 磁盘 阵列 的 Cache 配 置 很 容易 达到 上 限 ， 也 就 是 Raid 5 的 
处 理 能 力 受 到 Cache 限 制 ， 而 大 部 分 的 磁盘 阵列 都 可 以 扩充 磁盘 以 增加 带宽 ， 相 对 Raid 1+ 0 受到 的 性 能 限制 会 更 少 。 此 外 ，Raid 5 的 处 理 能 力 还 受 
到 校 验算 法 的 限制 。 


6. 不 同 Raid 的 性 能 和 可 靠 性 比较 


下 面 以 4 块 硬盘 组 构成 Raid 来 进行 比较 ， 如 表 8-2 所 示 。 


表 8-2 不同 Raid 的 性 能 和 可 靠 性 比较 


T EUITT 


随机 读 : 最 好 随机 写 : 最 好 

并 发 性 : 4 x Disk 并 发 性 : 4 x Disk 
顺序 读 : 最 好 顺序 写 : 最 好 
带宽 : 4 x Disk 带宽 : 4 x Disk 
随机 读 : 最 好 随机 写 : 一 般 

并 发 性 : 4 x Disk 并 发 性 : 2 x Disk 
顺序 读 : 很 好 顺序 写 : 一 般 
带宽 : 2 x Disk 带宽 : 2 x Disk 
随机 读 : 最 好 随机 写 : 一 般 

并 发 性 : 4 x Disk 并 发 性 : 2 x Disk 
顺序 读 : 很 好 顺序 写 : 一 般 
带宽 : 2 x Disk 带宽 : 2 x Disk 
随机 读 : 较 好 随机 写 : 

并 发 性 : 3 x Disk 并 发 性 : 1 x Disk 
顺序 读 : 较 好 顺序 写 : 较 好 
带宽 : 3 x Disk 带宽 : 3 x Disk 


由 于 Raid 5 人 存储 系统 高 度 依赖 于 Cache 性 能 ， 其 运行 会 随 着 业务 的 发 展 具 有 相对 的 不 稳定 性 。 作 为 一 个 Oracle 性 能 优化 工作 者 ， 相 信和 即使 存储 
系统 有 再 大 的 Cache 也 会 被 塞 满 ， 从 而 最 终 依赖 于 底层 磁盘 能 力 的 供给 ， 因 此 我 们 会 优先 采用 Raid 1+0 甚 至 总 是 建议 采用 Raid 1+0, 


图 8-15 所 示 的 性 能 测试 比较 图 源 于 互联 网 。 
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图 8-15 Raid 5 和 Raid 10 的 性 能 比较 


7.LUN 和 磁盘 队列 长 度 


LUN 是 存储 系统 提供 给 主机 的 可 发 现 设 备 ， 从 主机 的 角度 来 看 ，LUN 就 是 物理 磁盘 。 从 存储 的 角度 来 看 ，LUN 是 一 种 划分 出 来 的 逻辑 磁 
盘 ，RAID 的 直接 结果 就 是 一 个 逻辑 磁盘 ， 很 多 时 候 这 个 逻辑 磁盘 会 直接 通过 LUN 提 供给 主机 系统 。 


LUN Disk 的 背后 往往 是 由 包含 一 堆 磁 盘 的 Raid 构 成 的 ， 其 处 理 能 力 就 是 其 包含 的 磁盘 数量 的 处 理 能 力 ， 默 认 的 磁盘 队列 长 度 通 常 不 足以 反映 
其 处 理 能 力 。 总 体 而 言 ， 处 理 能 力 越 强 的 LUN 就 越 需要 更 高 的 磁盘 队列 长 度 。 磁 盘 队 列 长 度 事实 上 是 一 种 流 控 技 术 ， 当 长 度 设置 不 足 时 会 导致 处 理 
能 力 闲 置 ， 当 长 度 设 置 过 高 时 会 导致 磁盘 过 载 而 使 性 能 下 降 。 


在 AIX 系 统 下 修改 磁盘 队列 长 度 时 ， 可 通过 如 下 命令 查看 : 


lsattr -EL hdisk2|grep queue depth 


修改 命令 如 下 : 


hdev -1 hdiskX -a queue depth-64 -P 


Linux 下 面 修改 磁盘 队列 长 度 的 具体 代码 如 下 : 


echo "Set Scheduler" 

echo deadline > /sys/block/$sdx/queue/scheduler 
cat /sys/block/$sdx/queue/scheduler 

echo: eaaa " 

# 

echo "Set nr requests" 

echo 256 > /sys/block/$sdx/queue/nr requests 
cat /sys/block/$sdx/queue/nr requests 

écho "uem " 

# 

echo "Set queue_depth" 

echo 256 > /sys/block/$sdx/device/queue depth 
cat /sys/block/$sdx/device/queue depth 

echó. T= " 


8.7 ”磁盘 多 路 径 访 问 和 基于 存储 的 容 灾 复 制 影响 


8.7.1 磁盘 多 路 径 访 问 


当 一 块 磁盘 设备 可 以 被 多 条 物理 链 路 途径 访问 时 ， 该 磁盘 访问 就 具备 提高 并 发 性 访问 的 能 力 。 在 操作 系统 层面 ， 如 果 没有 做 过 特别 处 理 ， 一 块 
物理 磁盘 的 每 条 访问 路 径 都 会 体现 为 一 个 磁盘 设备 。 图 8-16 简 单 体现 了 多 路 径 访问 的 作用 层次 。 


多 路 径 负载 均衡 和 可 靠 性 保证 已 经 成 为 现代 磁盘 访问 的 标准 ， 几 乎 所 有 的 操作 系统 厂商 、 存 储 厂 商 、 卷 管理 器 厂商 都 提供 了 自身 的 多 路 径 管理 


操作 系统 自身 的 多 路 径 功 能 如 下 : 
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图 8-16 ”多 路 径 访问 作用 于 磁盘 阵列 
- ATX MPIO 
: HP-UX PV-LINK 4# Native. Multi-Path 
: LinuxDevice-MapperMultipath 
- SolarisMultiplexedI/O (MPxIO) 
: WindowsMPIODftriver 
独立 的 多 路 径 软 件 为 : 
: EMCPowerPath 
: IBMSDD 
< Veritas Volume Manager. (VxVM) 
: HP StorageWorks Secure Path 
- Hitachi HiCommand Dynamic Link Manager (HDLM) 


在 存储 系统 实践 中 ， 我 们 应 该 在 任何 时 候 都 构建 多 路 径 访问 。 多 路 径 访问 特别 是 和 Raid 1 组 合 可 以 大 幅 提高 并 发 能 力 甚至 响应 时 间 。 多 路 径 访 
问 除了 可 以 提高 存储 访问 性 能 外 ， 还 可 以 实现 高 可 用 性 ， 可 以 在 不 同 路 径 之 间 进 行 failover 访 问 。 


8.8 固态 硬盘 和 PCle 


8.8.1 固态 硬盘 和 传统 机 械 硬盘 


国 态 硬盘 是 存储 领域 的 真正 飞跃 ， 使 存储 系统 的 处 理 能 力 不 再 远 远 地 落后 于 内 存 ， 而 是 达到 | 一 个 可 比较 的 程度 。 特 别 是 PCle 的 应 用 和 普及 ， 必 
将 使 数据 中 心 的 基础 网 络 发 生 巨大 的 变化 。 


磁盘 的 最 大 问题 在 于 其 本 身 的 机 械 构造 ， 机 械 定位 导致 其 不 可 避免 的 平均 访问 延迟 必然 达到 ms 级 别 ， 甚 至 达到 10ms 级 别 。 由 于 磁头 定位 导致 


的 访问 延迟 使 每 张 磁盘 只 能 提供 200~300 个 ijops。 当 业务 需要 100000iops 支 撑 的 时 候 ， 则 至 少 需要 500 张 磁盘 或 大 容量 CACHE 的 支撑 。 即 使 通过 
巨 量 磁盘 的 堆 晋 ， 也 可 以 达到 带宽 的 需求 ， 但 磁盘 本 身 的 高 延迟 在 很 多 时 候 依 然 无 法 满足 业务 的 需求 。 


固态 硬盘 和 磁盘 的 比较 ( 引 自 SSD vs.HDD Pricing: Seven Myths That Need Correcting) 如 表 8-3 所 示 。 
表 8-3 ”消费 级 SSD、 企 业 级 SSD 和 机 械 硬盘 的 比较 


消费 级 SSD(Consumer SSD)、 企 业 级 SSD 和 机 械 硬 盘 的 比较 (Enterprise SSD, and HDD Comparison) 


4KB 随机 | 4KB 随机 | 接口 
g i 页 序 读 带 页 序 写 带 
a 品 设备 顺序 读 带 宽 顺序 写 市 宽 读 IOPS | 5 IOPS 类 型 
Ran. 


. Read Bandwidth | Write Bandwidth | Ran.Read | Ran. Write 
Product Device* . . Interface 
(Sequential GB/s) | (Sequential GB/s) |IOPS 4K  |IOPS 4K 
Fusion io Drive2 Duo (SLC) E-SSD 580000 | 535000 | PCIe 


( 续 ) 


rel 
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消费 级 SSD(Consumer SSD)、 企 业 级 SSD 和 机 械 硬 盘 的 比较 (Enterprise SSD, and HDD Comparison) 


4KB 随机 | 4KB 随机 | 接口 
ti i nie 页 序 5H 
产 品 顺序 读 带 宽 顺序 写 带 读 IOPS | S loPs 类 型 


Micron RealSSD P420m HHHL PCIe 
Micron RealSSD P320h HHHL PCIE SSD PCIe 
Samsung 840 Pro SATA 
Crucial (Micron)M550 SATA 
Crucial (Micron)M550 SATA 
Super Talent RAIDDrive I| Plus PCIe 
Super Talent RAIDDrive 12 PCIe 
DCZ Talos 2 SAS 
HP SSD SAS SAS 


从 表 8-2 可 以 看 到 ，SSD 和 传统 机 械 磁 盘 有 巨大 的 性 能 差异 。 特 别 是 其 提供 了 超过 10 万 的 iops 甚 至 达到 了 百 万 的 iops， 这 是 机 械 磁 盘 所 完全 无 
法 想象 的 。 在 看 到 巨大 的 iops 的 基础 上 ， 也 可 以 看 到 带宽 或 者 持续 读 能 力 并 没有 太 大 的 区 别 。 即 使 是 表格 中 最 高 的 带宽 (3.3GB) ， 也 仪 需 
15~30 块 磁盘 就 可 以 提供 类 似 的 带宽 和 顺序 读 能 力 。 


4| 


在 SSD 提 供 巨大 性 能 收益 的 同时 ， 我 们 需要 保持 冷静 ， 明 了 SSsD 的 特征 ， 然 后 最 好 地 使 用 它 。 


8.9 随机 访问 和 顺序 访问 


1. 随 机 MO 和 顺序 MO 


了 解 随 机 /O 和 顺序 VO 的 特征 是 优化 数据 库 /O 资 源 的 前 提 条 件 。 不 管 是 对 磁盘 、 文 件 系统 、LV， 还 是 对 数据 库 来 说 ， 顺 序 /O 都 表示 持续 读 
取 超 过 一 个 block 的 数据 ， 而 随机 MO 则 表示 仪 读 取 一 个 block 的 数据 。 随 机 MO 和 顺序 MO 的 区 别 之 所 以 重要 ， 主 要 还 是 由 磁盘 的 特性 决定 的 。 磁 盘 
在 访问 任何 数据 之 前 ， 首 先 要 进行 磁头 的 径 向 运动 和 旋转 运动 ， 也 就 是 所 谓 的 寻 道 延迟 和 旋转 延迟 。 从 前 面 介绍 的 磁盘 章节 可 以 知道 ， 在 访问 小 规 
模 的 数据 时 ， 比 如 几 KB 的 数据 ， 寻 道 延迟 和 旋转 延迟 决定 着 |/O 的 访问 速度 。 但 是 ， 随 着 持续 访问 数据 量 的 增加 ， 比 如 达到 | 兆 字 节 级 别 的 数据 ， 读 
取 数 据 将 成 为 决定 性 因素 。 


我 们 来 重复 磁盘 章节 的 计算 : 

平均 寻 道 延迟 : 5ms 

平均 旋转 延迟 : 3ms 

数据 传输 率 : 100m/s 

读 取 8KB 的 数据 访问 延迟 : 5+3+8x1000/ (100x1024) =8.078ms 
读 取 1MB 的 数据 访问 延迟 : 5+3+1x1000/100=18ms 

读 取 4MB 的 数据 访问 延迟 : 5+3+4x1000/100=48ms 


由 上 可 知 ， 随 着 持续 读 取 数据 量 的 增多 ， 寻 道 延 迟 和 平均 延迟 影响 将 快速 下 降 。 换 句 话说 ， 磁 盘 具 备 出 色 的 顺序 I/O 访 问 能 力 ， 但 是 随机 1/O 的 
能 力 比较 弱 。 


2.Oracle 的 随机 MO 和 顺序 MO 


对 于 Oracle 来 说， 任何 仅 访 问 一 个 Oracle block size 的 访问 都 表示 为 随机 lI/O， 超 过 一 个 block 的 访问 都 表示 为 顺序 |//O。 绝 大 部 分 OLTP 系 统 都 
是 随机 IO 远 远 大 于 顺序 MO， 而 DSS 系统 则 是 大 规模 地 应 用 顺序 MO。 简 单 来 说， 绝 大 多 数 的 索引 访问 都 会 进行 随机 MO 访问 ， 而 全 表 扫 描 和 索引 快 
速 扫描 则 会 进行 顺序 MO 访问 。Oracle 为 了 让 用 户 更 容易 看 到 I/O 问 题 所 在 ， 对 随机 IO 给 出 了 DB file sequence read 等 待 事件 ， 对 顺序 |/O 给 出 了 
DB file scattered read 等 待 事 件 。 这 里 需要 指出 的 是 ， 全 表 扫 描 并 不 一 定 进行 顺序 MO， 也 有 可 能 出 现 DB file sequential read 等 待 事件 。 比 如 图 
8-24 是 一 次 全 表 扫 描 访问 的 Block 分 布 。 


Disk Cache Block Cache Block Cache Block Cache 


图 8-24 ”数据 块 在 磁盘 和 buffer cache 之 间 的 间隔 分 布 


8 个 block， 按 1 个 block 在 磁盘 、1 个 在 buffer cache 的 顺序 分 配 ，Oracle 为 了 完成 读 取 这 8 个 块 ， 必 须 执 行 4 次 随机 MO 和 8 次 逻辑 MO， 这 时 的 
等 待 事件 就 体现 为 DB file sequential read。 显 然 一 次 性 从 磁盘 读 取 8 个 block 的 操作 速度 要 远 远 快 于 需要 4 次 读 取 ， 每 次 读 取 1 个 block 的 操作 。 为 
了 改善 这 种 情况 ，Oracle 11gR2 针 对 这 种 情况 给 出 了 serial read， 也 就 是 说 ， 首 先 把 cache 中 修改 过 的 block 写 入 磁盘 ， 然 后 从 磁盘 执行 direct 


read。 


3.online redo logfile 的 MO 


对 于 Oracle 来 说 ，online redo logfile 的 写 入 是 典型 的 顺序 MO， 也 就 是 说， 会 持续 地 进行 MO 写 入 ， 虽 然 每 次 VO 的 规模 不 大 。 理 想 情 况 下 ， 
如 果 磁 盘 设 备 为 online redo log 独 占 使 用 ， 磁 盘 上 则 会 同样 表现 为 顺序 MO， 几 乎 不 会 涉及 磁头 移动 ， 总 是 在 持续 地 写 数 据 。 不 考虑 其 他 方面 的 开 
销 ，online redo logfile 甚 至 可 以 以 100MB/s 的 速度 运行 ， 以 每 个 事务 2KB 大 小 计算 ， 一 个 磁盘 就 可 以 支持 每 秒 100*1024/2= 51200 个 事务 。 但 在 
现实 的 业务 系统 设计 中 ， 很 少 有 数据 库 设 计 为 online redo logfile， 并 采用 独立 磁盘 ， 通 常 总 是 和 其 他 数据 文件 混合 存放 在 一 个 磁盘 里 。 这 时 
Oracle 数 据 库 的 事务 吞吐 量 会 出 现 急剧 恶化 ， 假 设 极端 情况 每 2KB 执 行 一 次 redo 写 ， 这 时 的 事务 吞吐 量 则 每 秒 为 1000/ (5+3) =125 个 事务 。 虽 然 
Oracle 设 计 了 group commit 等 机 制 来 提高 redo write 的 效率 ， 但 无 论 如 何 ， 其 事务 吞吐 量 不 会 在 同一 个 数量 级 上 。 


4. 混 合 I/O 对 持续 数据 处 理 的 影响 


假设 对 一 个 16GB 的 大 型 表格 做 全 表 扫 描 ， 理 想 情 况 下 在 一 张 磁盘 的 支持 下 扫描 这 个 16GB 的 表格 需要 耗 时 16*1024/100=164s。 但 是 在 混合 
I/O 场 景 下 会 发 生 剧烈 的 变化 ， 假 设 全 表 扫 描 以 1MB 大 小 的 |/ 发 布 给 磁盘 系统 ， 需 要 发 布 |/O 次 数 为 16*1024=16384。 每 个 |/O 的 耗 时 为 
5+3+1*1000/100=18ms， 总 耗 时 为 295s， 响 应 时 间 大 幅 增加 。 


5.Oracle 数 据 库 的 MO 大 小 限制 和 存储 系统 的 MO 大 小 限制 


不 管 是 Oracle 还 是 操作 系统 ， 或 者 是 存储 系统 ， 都 会 对 每 次 的 |/O 大 小 进行 限制 ， 以 避免 某 个 业务 完全 独占 资源 。 对 Oracle 来 说 ,该 大 小 受到 
参数 db file_multiblock_read_count 的 影响 。db_block_size*db file_multiblock_read_count 就 是 Oracle 所 能 发 布 的 一 次 |/O 最 大 限制 ， 具 体 到 达 
磁盘 的 I/O 大 小 还 要 受到 操作 系统 、 磁 盘 阵列 等 的 限制 。 一 般 来 说 ， 操 作 系统 和 存储 系统 的 最 大 MO 设置 为 IMB。 当 Oracle MO 大 小 大 于 操作 系统 限 
制 的 时 候 ， 操 作 系统 会 把 MO 进行 分 拆 ， 发 布 多 次 MO 到 磁盘 系统 。 


在 Oracle 10g 以 上 版 本 中 ， 会 自动 检测 可 用 的 最 大 MO 大 小 。 在 不 知道 如 何 查看 操作 系统 和 存储 系统 的 MO 大 小 的 时 候 ， 可 以 简单 利用 图 8-25 
所 示 的 方式 来 查看 。 


SQL» show parameters db file multiblock 


db file multiblock read count integer 
SQL» alter system set db file multiblock read count-10000; 


System altered. 


SQL» show parameters db file multiblock 


db file multiblock read count integer 128 
sQL» li 


图 8-25 ”查看 可 用 的 最 大 LI/O 


8.10 ”基于 Oracle 数 据 库 的 存储 系统 设计 


8.10.1 Oracle online redo logfile 和 磁盘 阵列 


Oracle online redo logfile 是 Oracle 数 据 库 系统 最 大 的 串 行 点 ， 其 他 任何 串 行 点 的 影响 都 无 法 和 online redo logfile 相 比较 。oracle online 
redo logfile 是 一 个 典型 的 顺序 写 /O 操 作 ， 而 且 每 次 VO 的 规模 都 比较 小 。 为 了 支持 online redo logfile 的 高 吞吐 量 ， 必 须 让 Oracle online redo 
logfile 独 占 磁盘 ， 且 没有 其 他 进程 和 gwr 进 程 争夺 磁盘 资源 。 


绝 大 部 分 业务 系统 每 次 redo writes 的 规模 都 比较 小 ， 很 少 有 磁盘 阵列 的 条 带 化 可 以 在 几 KB 规模 的 情况 下 获得 良好 性 能 ， 也 就 是 任何 条 带 化 的 
Raid 不 会 给 lIgwr 写 redo logfile 带 来 性 能 改善 。 基 于 以 上 考虑 ， 应 该 遵循 以 下 设计 实践 。 


- 每 个 磁盘 存放 1 个 online redo logfile member. 
“ 每 个 磁盘 做 镜像 。 
“ 磁盘 的 队列 长 度 不 需要 太 高 ， 基 本 维持 默认 值 即 可 。 


如 果 磁 盘 阵 列 支 持 基 于 LUN 的 独立 cache 设 置 ， 则 logfile LUN 设 置 更 大 的 写 cache。 


如 果 磁 盘 数 量 无 法 支撑 每 个 磁盘 存放 1 个 tredo logfile membet， 则 可 以 把 所 有 的 Redo Group 放 置 在 相同 磁盘 上 。 


- 在 无 法 做 到 独立 存储 磁盘 的 时 候 ， 可 以 选择 SSD 作 为 online redo logfile 的 存储 空间 。 


8.11 ”1/0O 子 系统 的 运行 性 能 衡量 


8.11.1. 1/O 子 系统 运行 性 能 的 衡量 指标 
MO 子 系统 最 终 为 一 个 LUN Disk (一 个 块 设备 ) 反映 到 主机 上 。 可 以 基于 该 LUN 设 备 衡量 总 体 的 运行 性 能 。 对 于 |/0 子 系统 ， 主 要 通过 以 下 元 
素来 衡量 性 能 。 


“ 磁盘 利用 率 : 磁盘 系统 处 于 忙碌 度 的 百分比 。 需 要 注意 的 是 ， 该 指标 对 Raid 系 统 会 出 现 失 真 ， 由 于 无 法 认识 到 Raid 由 多 块 磁盘 构成 ， 只 要 磁 
盘 组 中 一 块 磁盘 处 于 忙碌 状态 ， 磁 盘 就 会 标记 为 已 经 利用 ， 从 而 给 磁盘 利用 率 带 来 错误 的 统计 。 由 于 Raid 在 实际 环境 中 已 普遍 使 用 ， 因 此 磁盘 利用 
只 有 一 定 的 参照 价值 ， 无 法 作为 磁盘 运行 性 能 的 绝对 衡量 指标 。 


: CPU I/O wait: CPU 由 于 等 待 /O 响 应 处 于 空闲 状态 。 该 指标 可 以 反映 I/O 子 系统 的 运行 性 能 在 全 局 业务 中 的 反映 。 即 使 /O 子 系统 本 身 的 统 
计 状 况 很 差 ， 但 是 全 局 表现 尚 可 ，I/O 子 系统 的 优化 可 能 不 会 成 为 最 迫切 的 要 务 。 


-iops: 每 秒 相应 的 IO 次数， 是 衡量 磁盘 运行 的 核心 指标 。 
: mbytes: 每 秒 访 问 的 字 节 兆 数 ， 是 衡量 磁盘 运行 的 核心 指标 。 


running queue length: 磁盘 队列 的 运行 平均 长 度 。 该 指标 直接 反映 了 磁盘 系统 是 处 于 超载 运行 状态 ， 还 是 正常 运行 状态 ， 或 者 低 负载 运行 状 


average response time: 指令 从 发 布 到 磁盘 到 返回 结果 的 响应 时 间 ， 包 含 在 队列 中 等 待 时 间 和 真正 的 磁盘 服务 时 间 。 该 指标 应 该 与 queue length 
一 致 ， 直 接 反 映 了 磁盘 系统 的 负载 状态 


average service time: 该 指标 反应 了 磁盘 系统 一 次 的 1/O 〇 服务 能 力 ， 该 值 反映 磁盘 系统 是 否 处 于 正常 工作 状态 。 任 何 时 候 该 值 应 该 处 于 正常 的 
响应 范畴 ， 比 如 低 于 20ms。 任 何 高 于 特定 值 的 响应 意味 着 磁盘 系统 出 现 问题 或 者 存储 系统 Cache 完 全 失效 等 。 


sar 命 令 和 iostat 命 令 都 可 以 反映 |/O 子 系统 的 运行 状况 ， 如 图 8-26 和 图 8-27 所 示 。 


[oraclegtest dbs]$ sar -d 2 5 
Linux 2.6.39-400.17.1.el6uek.x86 64 (test) 10/21/2014 x86 64 (1 CPU) 


11:49:20 
11:49:22 
11:49:22 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 


11:49:22 
11:49:24 
11:49:24 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 1.01 0.00 32.16 32.00 0.00 0.50 0.50 


11: 
11: 
13* 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 3.03 0.00 80.81 26.67 0.01 1.83 1.17 


11: 
11: 
11: 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 


11: 
11: 
11: 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 1.02 0.00 32.49 32.00 0.00 1.50 1.50 


zzz ZZZ zzi zi zzi 


Average: DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
Average: dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
Average: dev8-8 1.01 0.00 29.18 28.80 0.00 1.50 1.18 


图 8-26 sat 命 令 查看 I/O 子 系统 的 运行 状况 


[oracle@test dbs]$ iostat -d -x 2 5 
Linux 2.6.39-400.17.1.el6uek.x86 64 (test) 10/21/2014 x86 64. (1 CPU) 


Device: rrqm/s  wrqm/s r/s rsec/s  wsec/s avgrq-sz avgqu-sz await svctm 
fdo 0.00 0.00 0.00 0.01 0.00 8.00 0.00 33.00 33.00 
sda 0.77 24.39 136.31 3581.52 2212.54 26.55 0.34 1.54 0.32 


Device: rrqm/s  wrqm/s r/s rsec/s  wsec/s avgrq-sz avgqu-sz await svctm 
fdo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
sda 0.00 1.00 0.00 0.00 56.00 18.67 0.00 0.67 0.50 


Device: rrqm/s wrqm/s r/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm 
fde 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.900 
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 60.00 


Device: rrqm/s | wrqm/s r/s rsec/s  wsec/s avgrq-sz avgqu-sz await svctm 
fdo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 60.00 
sda 0.00 1.06 0.00 0.00 59.57 18.67 0.00 0.33 0.33 


Device: rrqm/s wrqm/s r/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm 
fdo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.900 
sda 0.00 0.00 0.00 0.00 32.99 32.00 0.00 0.50 60.50 


图 8-27 iostat 命 令 查看 I/O 子 系统 的 运行 状况 


812 ” 几 个 MO 子 系统 资源 常见 问题 的 讨论 


8.121 MO 资源 极度 紧张 但 MO wait 表 现 不 高 


我 们 有 时 候 会 发 现 sar-u 或 者 vmstat 中 的 %iowait 比 例 不 高 ， 
匹配 。 图 8-36 中 的 命令 仅 表 示 为 样式 ， 数 据 不 作为 评判 依据 。 


i 
m 


晶 是 通过 sar-d 或 者 iostat 发 现 ， 运 行 磁盘 几乎 都 在 100%， 两 者 的 表现 似乎 不 是 很 


[oraclegtest dbs]$ sar -u 2 2 
Linux 2.6.39-400.17.1.el6uek.x86 64 (test) 10/22/2014 x86 64. (1 CPU) 


01:04:11 AM CPU *user *nice system  %iowait *steal %idle 
01:04:13 AM all 2.05 0.00 1.03 0.00 0.00 96.92 
01:04:15 AM all 2.05 0.00 1.54 0.00 0.00 96.41 
Average: all 2.05 0.00 1.28 0.00 0.00 96.67 
[oraclegtest dbs]$ sar -d 22 

Linux 2.6.39-400.17.1.el6uek.x86 64 (test) 10/22/2014 X86 64 (1 CPU) 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 3.14 8.38 67.02 24.00 0.00 0.50 0.50 


DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
dev8-0 2.59 0.00 41.45 16.00 0.00 1.60 0.40 


Average: DEV tps rd sec/s wr sec/s avgrq-sz avgqu-sz await svctm 
Average: dev2-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 
Average: dev8-0 2.86 4.17 54.17 20.36 0.00 1.00 0.45 
[oracle@test dbs]$ Bi 


图 8-36 ”sar-u 和 sat-d 命 令 


sar-u 命 令 体现 的 是 CPU 的 繁忙 度 ， 其 中 %iowait 表 示 这 部 分 的 CPU 处 于 空闲 状态 ， 业 务 进程 在 等 待 MO 响 应 。 随 着 CPU 资源 的 紧张 ， 在 相同 的 
MO 下 会 发 现 %iowait 越 来 越 低 ， 也 就 是 说， 这 些 空闲 CPU 资源 在 不 断 地 被 利用 ， 在 AIO 支 持 的 系统 中 ， 这 种 情况 会 比较 常见 ， 甚 至 会 出 现 MO 
100% 被 使 用 同时 %iowait=0 的 情况 。 前 面 介绍 过 ，%iowait 反 映 的 是 MO 子 系统 在 全 局 中 对 业务 响应 的 影响 度 ， 其 值 越 低 ， 影 响 度 也 越 低 。 在 一 
个 %iowait=0 且 Disk utility 100% 的 业务 系统 中 ， 决 定 其 运行 效率 的 是 CPU 资源 ， 而 不 是 MO 资源 。 


8.13 ”1/O 子 系统 资源 优化 的 目标 和 道路 


813.1 ”I/O 资源 问题 的 场景 和 优化 道路 


几乎 所 有 的 MO 资源 问题 都 是 由 以 下 原因 造成 的 。 

. 存储 系统 故障 ， 包 含 硬 故 障 、 软 故障 和 配置 故障 。 

. 存储 系统 全 局 承载 过 大 的 I/O 压 力 ， 导 致 性 能 不 佳 。 
. 存储 系统 局 部 承载 过 大 的 I/O 压 力 ， 导 致 性 能 不 佳 。 
.Oracle 数据 库存 储 设 计 不 当 导致 性 能 不 佳 。 

.Oracle 参数 配置 不 当 导 致 性 能 不 佳 。 

在 明确 了 I/O 资 源 问题 后 ， 只 要 进行 针对 性 优化 即 可 ， 措 施 也 非常 简单 。 
: 明确 存储 故障 ， 修 正 配 置 或 者 修复 存储 。 

- 降低 存储 系统 的 全 局 I/O 〇 压力 。 

' 分 布 存 储 系 统 压 力 ， 使 每 个 I/O 设 备 处 于 合理 范畴 。 
: 优化 Oracle 数 据 库 I/O 设 计 ， 充 分 发 挥 硬件 系统 效能 。 


图 8-38 展 示 了 如 何 去 优 化 MO 问题 导致 的 性 能 故障 。 


IO 问题 


确保 LO 


降低 IO 压力 分 布 VO 压力 


部 件 正常 


优化 VO 配置 


J s 


图 8-38 I/O 〇 性 能 问题 的 排查 顺序 


8.14 ”1/O 子 系统 资源 优化 案例 


1.SAN 交 换 机 故障 导致 业务 系统 响应 缓慢 


某 运 营 商业 务 系统 运行 突然 变 慢 ， 从 AWR 报 告 可 以 看 出 MO 响应 缓慢 ，DB file scattered read 和 DB file sequential read 都 分 别 超过 40ms。 
单个 服务 的 响应 延迟 ， 首 先 要 确认 存储 系统 是 否 存 在 问题 。 检 查 errpt 发 现 fc hba 卡 报告 错误 ， 检 查 另 外 的 主机 也 发 现 了 这 个 错误 ， 考 虑 很 少 会 有 
不 同 主机 上 的 fc hba 卡 同时 同 错 ， 检 查 共同 的 san 交 换 机 ， 发 现 是 SAN 交 换 机 故障 。SAN 交 换 机 故障 使 存储 系统 的 吞吐 量 降低 到 原先 的 50%，MO 
响应 自然 就 变 慢 了 。 


2.Raid 5 失败 重组 导致 业务 系统 响应 缓慢 


某 运 营 商 业务 系统 发 现 响应 极为 缓慢 ， 而 且 已 经 持续 了 一 段 时 间 。 从 AWR 报 告发 现 |/O 响 应 已 经 达到 100ms 以 上 ， 检 查 操作 系统 errpt， 发 现 报 
告 磁盘 失败 。 检 查 Raid 组 ， 发 现 正 在 进行 Raid 5 重组 ， 产 生 大 量 的 MO 资源 消耗 。Raid 5 重组 是 存储 系统 比较 常见 的 性 能 故障 ， 可 以 简单 地 通过 检 
查 操作 系统 日 志 以 及 存储 柜 信号 发 现 。 


3. 存 储 系统 cache 电 池 故 障 导致 业务 系统 响应 缓慢 


某 制造 公司 的 业务 系统 响应 缓慢 ， 检 查 AWR 报 告 磁盘 |/O 响 应 速度 很 慢 ， 达 到 50ms 以 上 的 响应 延迟 。 检 查 操作 系统 错误 日 志 发 现存 储 系统 
cache 电 池 告 警 ， 导 致 Raid 5 的 性 能 快速 下 降 。Raid 5cache 失 效 是 极其 常见 的 存储 系统 故障 ， 其 表象 就 是 |/O 单 元 响应 缓慢 ， 尤 其 是 dbwr 写 和 log 
写 的 效能 很 差 。 


4. 网 络 内 断 导致 远程 复制 工作 异常 


某 运营 商 发 现 业 务 响 应 缓慢 ， 基 本 处 于 挂 起 状态 ,数据 库存 在 大 量 的 等 待 |/O 事 件 。 检 查 操 作 系统 ， 没 有 相关 错误 ， 检 查 操作 系统 性 能 数据 ， 
发 现 磁盘 利用 率 100%，tps 和 mbytes 基 本 为 零 。 由 此 可 以 确认 存储 系统 的 某 个 环节 出 现 问 题 ， 检 查 远程 复制 日 志 ， 发 现 网 络 内 断 场景 ， 切 换 远程 
复制 从 同步 到 异步 ， 业 务 恢复 正常 。 


5 远程 存储 复制 系统 性 能 异常 导致 生产 性 能 下 降 


某 卫生 局 系统 的 业务 响应 缓慢 ， 检 查 AWR 报 告发 现 MO 单 元 响应 达到 40ms 以 上 ， 检 查 业 务 系统 吞吐 量 并 没有 发 现 /MO 消耗 增加 。 基 本 可 以 判断 
存储 系统 问题 导致 业务 缓慢 ， 检 查 操作 系统 日 志 ， 没 有 发 现 相 关 错误 。 该 业务 系统 有 本 地 镜像 和 远程 镜像 ， 简 单 临 时 性 切断 复制 ， 业 务 系统 恢复 正 


常 。 


6. 卷 管理 器 复制 异常 导致 性 能 下 降 


某 社保 系统 的 业务 响应 缓慢 ， 检 查 AWR 报 告发 现 |/O 单 元 响应 达到 50ms 以 上 ， 检 查 业务 系统 吞吐 量 正常 ， 操 作 系统 错误 正常 。 该 系统 有 VxVM 
的 本 地 和 远程 镜像 ， 切 断 本 地 和 远程 镜像 ， 业 务 依然 表现 不 好 。 检 查 操 作 系统 MO 和 Oracle 系 统 I/O 差 异 量 ， 发 现 大 量 I/O 发 生 在 数据 库 外 ， 再 次 检 
查 VxVM ， 发 现 VxVM 持 续 在 做 镜像 增 量 同步 ， 导 致 其 占用 大 量 /O 带 宽 。 由 于 无 法 预知 其 增 量 同 步 何 时 完成 ， 也 不 知道 如 何 关 闭 它 ， 因 此 切换 部 
分 关键 文件 到 jfs2 文 件 系统 恢复 业务 性 能 。 在 实践 中 ， 虽 然 VxXVM 的 用 户 不 多 ， 但 几乎 每 个 VXVM 用 户 都 出 现 过 由 于 VxVM 导 致 的 业务 性 能 障碍 。 从 
队列 长 度 、 镜 像 同步 到 并 发 性 不 足 等 不 同 的 VXVM 故 障 现象 ， 由 于 我 们 自身 对 VxVM 的 认识 不 足 ， 在 很 多 场景 下 只 能 简单 地 切换 到 其 他 的 |vm。 


7.rman 备 份 导致 业务 系统 性 能 响应 缓慢 


某 运营 商 发 现 业 务 系统 性 能 有 所 降低 ， 检 查 AWR 报 告发 现 log MO 的 响应 时 间 不 高 ， 甚 至 有 时 候 会 达到 40ms 以 上 ， 一 般 在 20ms 左 右 。 随 机 MO 
和 顺序 /O 的 等 待 响应 略 有 增加 ， 检 查 I/O 知 吐 量 ， 发 现 physical read total bytes 比 以 往 有 大 幅度 增加 ， 但 是 physical read bytes 基 本 维持 不 变 。 
从 这 里 可 以 确认 发 生 了 一 些 类 似 于 rman 的 工作 ， 检 查 session 和 进程 ， 发 现 有 rman 备 份 在 进行 ， 占 用 大 量 /O， 因 此 停止 rman 恢 复业 务 。 


除了 rman 外 ， 类 似 的 这 类 故障 很 多 ， 比 如 发 起 一 个 大 型 ftp 或 者 cp， 发 起 一 个 临时 性 的 大 型 报表 都 会 产生 类 似 于 rman 备 份 的 效果 。 特 别 是 
rman， 由 于 大 部 分 rman 作 业 缺 乏 流 控 设 置 ， 一 旦 发 起 就 会 引起 业务 系统 由 于 MO 资 源 吃紧 而 瘫痪 。 


8. 业 务 系统 业务 规模 增长 导致 存储 系统 处 理 能 力 不 足 


某 运 营 商 业务 系统 发 现 性 能 有 所 降低 ， 检 查 AWR 报 告发 现 |/O 响 应 由 原来 的 5ms 增 加 到 10~20ms， 进 一 步 检查 业务 系统 的 |/O， 发 现 有 比较 大 
的 |/O 增 长 。 计 算 产 生 的 |/O， 确 定 其 已 经 接近 400m， 基 本 达到 两 块 2GB HBA 卡 的 理论 速度 。 用 户 通过 增加 HBA 卡 扩展 通道 吞吐 量 使 业务 恢复 正 


pr 


To 


9 .频繁 删除 更 新 的 接口 表 增 长 导致 O 资 源 消耗 大 幅度 增加 


某 运 营 商 业务 系统 的 主要 业务 响应 缓慢 ， 尤 其 是 某 特定 模块 特别 明显 。 检 查 AWR 报 告 ， 发 现 VO 响 应 时 间 略 有 上 升 ， 总 VO 量 大 幅度 增加 ， 使 
存储 系统 面临 比较 大 的 压力 。 检 查 Top segment 变化 的 MO 来 源 ， 发 现 /O 增 长 来 源 和 特定 模块 基本 一 致 。 检 查 发 现 一 张 总 维持 在 几 行 的 表格 现在 
已 经 增长 到 接近 200m ， 而 该 表格 访问 依赖 全 表 扫 描 进 行 。 简 单 重 组 该 表格 ， 恢 复业 务 。 根 据 笔 者 的 经 验 ， 要 对 该 表格 的 大 小 进行 持续 性 监视 ， 在 
需要 的 时 候 进 行 重组 。 


10. 通 过 cache 主 要 引用 表格 增加 性 能 


某 运 营 商 业务 系统 某 些 批 处 理性 能 不 是 非常 理想 ， 最 近 表 现 出 逐 月 下 跌 的 趋势 。 从 AWR 来 看 ， 主 要 的 障碍 来 自 于 表格 规模 的 自然 增长 和 1/O 数 
量 的 自然 增长 。 用 户 拥有 比较 多 的 内 存 ， 因 此 建立 keep 缓 存 ， 把 主要 的 客户 档案 表格 全 部 进行 keep， 系 统 的 MO 量 下 跌 了 30% 多 ， 批 处 理 业务 响应 
增长 明显 。 这 里 需要 注意 的 是 ，keep 缓 存 并 没有 对 交互 式 业 务 产 生 明 显 的 影响 。 在 这 里 ， 磁 盘 系 统 总 体 吞吐 能 力 尚 可 ， 只 是 明显 过 多 的 MO 导致 批 


处 理 响 应 不 稳定 。 
11. 光 纤 老 化 导致 VO 性 能 下 降 


某 药品 物流 企业 业务 系统 性 能 下 降 ，AWR 报 告 显 示 磁盘 读 从 原先 的 3~5ms 下 降 到 30~50ms， 而 业务 压力 和 I/O 压 力 并 没有 增加 。 检 查 之 后 定 
位 到 SAN 交 换 机 ，sfpshow 命 令 显示 发 现 port4 端 口 的 信号 强度 只 有 其 他 端口 的 50%， 于 是 通过 更 换 光 纤 恢 复 性 能 。 


第 9 章 ”资源 供给 : 网 络 子 系统 


9.1 简单 案例 分 享 


某 运 营 商 来 电 沟通 业务 系统 问题 ， 描 述 在 杭州 的 用 户 访问 速度 很 快 ， 但 是 绍兴 的 用 户 访问 速度 很 慢 。 问 两 者 之 间 有 什么 区 别 ， 回 答 说 一 个 是 
100MB 网 络 ， 一 个 是 10MB 网 络 。 再 问 是 否 只 有 特定 业务 有 问题 ， 回 答 说 只 有 一 笔 查询 业务 比较 慢 。 继 续 问 这 个 查询 是 否 返 回 大 量 的 数据 ， 回 答 说 
大 约 是 4000 条 数据 。OK， 到 了 这 里 ， 产 生 问题 的 原因 就 很 明显 了 ， 网 络 速 度 的 差异 导致 了 特定 操作 的 性 能 差异 ， 如 何 解决 ”将 网 络 升级 到 
100MB?” 显 然 要 被 人 敲 脑袋 的 。 解 决 方案 很 简单 : 增加 array fetch size， 减 少 网 络 间 交 互 ， 让 开发 商 修改 下 代码 就 可 以 了 。 


第 9 章 ”资源 供给 : 网 络 子 系统 


9.1 简单 案例 分 享 


某 运 营 商 来 电 沟 通 业务 系统 问题 ， 描 述 在 杭州 的 用 户 访 问 速度 很 快 ， 但 是 绍兴 的 用 户 访 问 速 度 很 慢 。 问 两 者 之 间 有 什么 区 别 ， 回 答 说 一 个 是 
100MB 网 络 ， 一 个 是 10MB 网 络 。 再 问 是 否 只 有 特定 业务 有 问题 ， 回 答 说 只 有 一 笔 查询 业务 比较 慢 。 继 续 问 这 个 查询 是 否 返 回 大 量 的 数据 ， 回 答 说 
大 约 是 4000 条 数据 。OK， 到 了 这 里 ， 产 生 问题 的 原因 就 很 明显 了 ， 网 络 速 度 的 差异 导致 了 特定 操作 的 性 能 差异 ， 如 何 解决 ”将 网 络 升级 到 
100MB? 显然 要 被 人 敲 脑袋 的 。 解 决 方案 很 简单 : 增加 array fetch size， 减 少 网 络 间 交互 ， 让 开发 商 修改 下 代码 就 可 以 了 。 


9.2 网络 子 系统 和 构成 

从 性 能 优化 的 角度 来 看 ， 网 络 子 系统 遭遇 的 性 能 问题 相对 其 他 部 件 会 更 少 ， 虽然 网 络 和 硬盘 一 样 是 主机 系统 中 速度 最 慢 的 设备 之 一 。 目 前 , 运 
行 中 的 业务 系统 主要 采用 10MB、100MB 和 1000MB 网 络 ， 部 分 主机 网 络 采用 10GE 网 络 或 |B 网 络 。 
9.3 网络 协议 : TCP、UDP 和 和 NFS 


Oracle 数 据 库 主 要 运行 在 TCP 协 议 之 上 ，SQL*Net 协 议 的 实现 基于 TCP。Oracle 在 某 些 地 方 基于 高 吞吐 量 的 需求 ， 采 用 UDP 实 现 性 能 最 大 化 ， 
主要 包括 Oracle RAC、Oracle Dataguard 的 日 志 传 输 等 服务 。 


9.4 网络 参数 配置 和 运行 性 能 


一 般 的 业务 网 络 ， 通 常 不 会 有 网 络 吞吐 量 方面 的 需求 ， 只 要 关心 其 正确 的 链 路 访问 顺序 即 可 。 本 章 涉及 的 网 络 优化 都 是 针对 高 速 的 内 联网 络 和 
低速 的 广域网 络 的 。 


9.5 网络 市 宽 的 扩展 


在 高 速 内 联网 络 中 ， 可 能 存在 着 单 块 网 卡 无 法 提供 足够 带宽 的 场景 。 这 时 可 以 通过 网 卡 捆绑 的 方式 来 提高 带宽 和 香 吐 量 ， 也 就 是 说 ， 通 过 把 两 
块 网 卡 捆绑 在 一 起 来 提供 给 业务 通信 使 用 。 为 了 扩展 带宽 ， 当 然 要 将 绑 定 模式 设置 为 负载 均衡 模式 。 


9.6 ”主要 的 网 络 性 能 监视 工具 


对 于 一 个 Oracle 性 能 优化 工作 者 来 说 ， 并 不 需要 很 复杂 的 网 络 性 能 监控 。 只 要 知道 如 何 监控 网 络 运行 统计 和 实时 网 络 流量 就 可 以 了 。 
1.ping 命 令 
ping 命 令 用 于 检测 网 络 的 连通 性 ， 并 获得 RTT 的 值 ， 而 RTT 是 网 络 性 能 中 最 为 重要 的 指标 之 一 。 相 关 代码 如 图 9-11 所 示 。 
[root@hcal ~]# n 172.16.80.75 
PING 172.16.80.75 (172.16.80.75) 56(84) bytes of data. 


64 bytes from 172.16.80.75: icmp seq-1 ttl-64 time-0.016 
64 bytes from 172.16.80.75: icmp seq-2 ttl-64 time=0. 027 


64 bytes from 172.16.80.75: icmp seq-3 ttl-64 time=0. 013 
64 bytes from 172.16.80.75: icmp seq-4 tt1=64 time-z0.013 
64 bytes from 172.16.80.75: icmp seq-5 ttl-64 time-0.027 
64 bytes from 172.16.80.75: icmp seq-6 tt1=64 time=0. 013 


图 9-11 ping 命 令 用 于 检测 网 络 的 连通 性 


2.ifconfig 命 令 


ifconfig 命 令 用 于 查看 网 卡 的 状态 ， 通 过 统计 信息 的 快照 统计 ， 可 以 获得 一 段 时 间 的 网 络 吞 吐 量 、 队 列 长 度 和 其 他 一 些 统计 信息 ， 如 errors、 
dropped、overruns、frame、collision 等 ， 代 码 截 图 如 图 9-12 所 示 。 


3.sar-n 命 令 


sar-n 命 令 用 于 发 现 网 络 的 实时 流量 ， 不 需要 像 ifconfig 命 令 一 样 自己 去 计算 快照 差 ， 而 是 可 以 直接 显示 网 络 运行 的 实时 流量 统计 ， 代 码 堆 图 如 
图 9- 1 3 所 示 。 


[root@hcal ~]# ifconfig ethO 
ethO Link encap:Ethernet  Hwaddr 78:2B:CB:14:B5:6A 
inet addr:172.16.80.75 Bcast:172.16.255.255 &Mask:255.255.0.0 
inet6 addr: fe80::7a2b:cbff:fei14:b56a/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
EX packets:56236 errors:O dropped:0 overruns:O frame:0 


PME :377 errors:O0 dropped:O overruns:O carrier:O 
collisions:O txqueuelen:1000 

RX bytes:4301131 (4.1 MiB) TX bytes:48563 (47.4 KiB) 
Interrupt:106 Memory:da000000-da012800 


[root@hcal ~]# 


图 9-12 ” ifconfig 命令 用 于 查看 网 卡 的 状态 


[rootéhcai ~]# sar -n DEV 5 2 
2.6.18-308.e15 (hcal) 10/28/2014 


PM IFACE di^ itur. rxbyt /s gc rxcmp/s txcmp/s rxmcst/s 
PM 1o 35.20 0.00 0.00 0.0 
PM etho 54: 2 4047. 26: 
PM ethi 0. p 0. 0. 
PM sito 0. : 0. 0. 
PM ibO 0. k 0. 0. 

ibi 0. : 0. 0. 


IFACE rxpck/s ac ER 
0.40 .40 
3968. 


0: 
0. 
0. 


Average: rxpck/s  txpck/s rxbyt/s 
Average: 0.60 0.60 26.40 
Average: 53. 

Average: 0. 0. 

Average: i 0. 0. 

Average: i 0 0 

Average: 0 0 

[rootéhcai ~]# J 


图 9-13 ”sat-n 命 令 用 于 发 现 网 络 的 实时 流 


A 


4.netstatáp S 


了 


netstat 命 令 是 监控 网 络 状态 的 主要 工具 ， 具 有 强大 的 功能 ， 几 乎 可 以 完成 网 络 统计 和 状态 的 任何 事情 。netstat 有 众多 参数 ， 这 里 就 不 介绍 
代码 截图 如 图 9-14 所 示 。 


[root&hcal ~]# netstat -r 
Kernel IP routing table 
Destination Gateway Genmask window irtt 
192.168.1.0 d 2 $ U 00 0 i 
192.168.1.0 
172.16.0.0 * 
169.254.0.0 * 
default 172.16.4.254 
[root@hcal ~]# netstat -i 
Kernel Interface table 

RX-OK RX-ERR RX-DRP RX-OVR 

0 0 


lo 16436 
[root@hcal ~]# J 


图 9-14  netstatép-4- JH] T 3 2 9] AARS 


[rootéhcal ~]# netstat -algrep tcp 
tcp hcal:bootserver 
tcp hca1:2208 

tcp *:sunrpc 

tcp *:ssh 

tcp * :1014 

tcp hcal:ipp 

tcp hcal:smtp 

tcp *:8090 

tcp 172.16.80.75:ssh 
tcp hcal1:15085 

tcp 172.16.80.75:ssh 
tcp *:ncube-1m 

tcp *:ssh 


tcp hcal:ncube-1m 
[rootéhcal ~]# J 


[root@hcal ~]# netstat -p 

Active Internet connections (w/o servers) 

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name 
tcp 0 0 172.16.80.75:ssh 172.16.4.11:54931 ESTABLISHED 6403/sshd 

tcp 0 0 hca1:15085 hcal:ncube-1m ESTABLISHED 5968/asm pmon. -ASM 
tcp 0 0 172.16.80.75:ssh 172.16.4.172:56900 ESTABLISHED 5826/sshd 

tcp 0 0 hcai:ncube-1m hcal1:15085 ESTABLISHED 5878/tnslsnr 
Active UNIX domain sockets (w/o servers) 

Proto Refcnt Flags Type State PID/Program name Path 

unix 2 1012/udevd &/org/kerne1 /udev/udevd 

unix 4914 /hald G/org/freedesktop/hal /udev. event 
unix 4422/syslogd /jdev91og 


LISTEN 

LISTEN 

LISTEN 

LISTEN 

LISTEN 

LISTEN 

LISTEN 

LISTEN 
.16.4.11:54931 ESTABLISHED 
:ncube- 1m ESTABLISHED 
.16.4.172:56900 ESTABLISHED 

LISTEN 

LISTEN 
:15085 ESTABLISHED 
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CONNECTED 
CONNECTED 

CONNECTED 

L CONNECTED 
CONNECTED 

CONNECTED 


CONNECTED 5859/oraagent.bin 
CONNECTED 5941/ocssd. bin /var /tmp/. oracle/sOCSSD. LL. hcal1.. 


VJ UJ UJ N UJ UJ UJ UJ UJ UJ 


[ 
[ 
| | CONNECTED 5875/evmd. bin /var /tmp/. oracle/SsSYSTEM. evm. acceptor. auth 


Lroot@hcal ~J# netstat -s 
Ip: 
14959 total packets received 
2828 with invalid addresses 
0 forwarded 
0 incoming packets discarded 
8372 incoming packets delivered 
4201 requests sent out 
135 ICMP messages received 
0 input ICMP message failed. 
ICMP input histogram: 
destination unreachable: 
echo requests: 63 
echo replies: 67 
141 ICMP messages sent 
0 ICMP messages failed 
ICMP output histogram: 
destination unreachable: 
echo request: 73 
echo replies: 63 
IcmpMsg: 
InTypeO: 
InType3: 
InType8: 
OutTypeO: 
OutType3: 
OutType8: 


602 active connections openings 
5 passive connection openings 
599 failed connection attempts 
1 connection resets received 

4 connections established 

3952 segments received 

3978 segments send out 

8 segments retransmited 

0 bad segments received. 

854 resets sent 


图 9-14 (5) 


580 packets received 

0 packets to unknown port received. 
0 packet receive errors 

67 packets sent 


TCcpExt : 
1 TCP sockets finished time wait in fast timer 
420 delayed acks sent 
404 packets header predicted 
506 acknowledgments not containing data received 


图 9-14 (5) 


5.nfsstat 命 令 


同 netstat 命 令 一 样 ，nfsstat 命 令 主要 用 于 查看 nfs 相 关 的 运行 统计 信息 。 代 码 截 图 如 图 9-15 所 示 。 


[root@hcal ~]# nfsstat -o all -3 


Server packet stats: 


peus 


udp tcp tcpconn 
0 4 3 


Server rpc stats: 


calls 
1 


IUE badcint badauth xdrcall 
0 3 


Server e. cache: 


hits 
0 


misses nocache 
0 1 


server file handle cache: 


lookup 
0 


anon ncachedir ncachedir stale 
0 0 0 0 


server nfs v3: 


nu11 

0 

read 

0 
remove 
0 


fsstat 
0 


[root&hcai 
traceroute 


1 172.16. 


[root&hcai 
traceroute 
[root&hcai 
traceroute 


1 172.16. 


[rootQhcal 
traceroute 


1 172.16. 


[root&hcai 
traceroute 
1 172.16. 
[root&hcai 
traceroute 

*v» ox * 


次 次 


[rootQhcal 


setattr lookup access readlink 
0 0% 0 0 0 


0% 
symlink mknod 
0% 0 


0 0% 
readdir readdirplus 
0 0 026 


图 9-15 ”nfsstat 命 令 用 于 查看 nfs 相 关 的 运行 统计 信息 


~]# traceroute 172.16.80.75 

to 172.16.80.75 (172.16.80.75), 30 hops max, 40 
80.75 (172.16.80.75) 0.030 ms 0.012 ms 0.006 
~]# traceroute 172.16.6.180 

to 172.16.6.180 (172.16.6.180), 30 hops max, 40 
~]# traceroute 172.16.80.76 

to 172.16.80.76 (172.16.80.76), 30 hops max, 40 
80.76 (172.16.80.76) 1.134 ms 1.137 ms 1.129 ms 
~]# traceroute 172.16.80.76 

to 172.16.80.76 (172.16.80.76), 30 hops max, 40 
80.76 (172.16.80.76) 0.158 ms 0.128 ms 0.119 ms 
~]# traceroute 172.16.80.100 

to 172.16.80.100 (172.16.80.100), 30 hops max, 40 byte packets 

80.75 (172.16.80.75) 3001.008 ms !H 3001. 004 ms IH 3000.997 ms !H 
~]# traceroute 172.16.4.11 

to 172.16.4.11 (172.16.4.11), 30 hops max, 40 byte packets 


e packets 


byte packets 
byte packets 


byte packets 


图 9-16 traceroute 4» 4- 


6.traceroutedp S 


当 发 现 有 比较 高 的 RTT 延 迟 时 ， 可 能 要 通过 traceroute 命 令 去 了 解 在 链 路 的 哪个 阶段 发 生 了 问题 。 在 性 能 优化 实践 中 ， 出 现 的 这 类 问题 较 多 ， 
不 过 ， 最 后 都 会 发 现 是 因为 网 络 包 走 了 不 该 走 的 链 路 ， 主 要 是 设置 问题 导致 的 。 代 码 截图 如 图 9-16 所 示 。 


9.7 ”网 络 子 系统 的 运行 性 能 衡量 


9.7.1 网络 子 系统 运行 性 能 的 衡量 指标 
网 络 子 系统 主要 通过 吞吐 量 和 延迟 时 间 来 衡量 性 能 ， 知 吐 量 类 似 于 iops 和 mbytes， 延 迟 时 间 则 表示 为 每 个 packet 的 延迟 时 间 。 
1.mbytes 和 packets 


mbytes 表 示 网 络 链 路 每 秒 钟 处 理 的 字 节 数 ，packets 表 示 网 络 链 路 每 秒 钟 处 理 的 包 数 量 。 


mbytes 和 packets 是 网 络 链 路 效率 处 理 的 核心 指标 ， 表 示 网 络 的 吞吐 量 。 网 络 带 宽 是 mbytes 的 极限 值 ， 可 以 期 待 在 即将 达到 极限 值 的 时 候 RTT 
会 快速 下 降 。 


mbytes 和 packets 可 以 进一步 区 分 为 接收 包 和 发 送 包 的 数量 。 

mbytes=send mbytes+recv mbytes 

packets=send packets+recv packets 

Packets 还 可 以 依据 不 同 的 协议 来 进行 区 分 ， 比 如 IP、icmp、icmpmsg 等 。 
2.RTT 

RTT 反 映 网 络 链 路 的 延迟 时 间 ， 是 业务 用 户 对 网 络 的 直接 反映 ,与 mbytes、packets 一 起 构成 网 络 性 能 的 核心 运行 指标 。 
3.collisions rate, errors, drops, overrunsf(lretransmited 


“ collisions rate: 拥塞 率 。 拥 塞 是 网 络 传输 不 可 避免 的 事件 ， 只 是 过 高 的 拥塞 率 意味 着 网 络 过 载 或 者 过 多 的 包 在 上 面 流动 。 拥 塞 会 导致 trp 重 传 
和 udp 丢 弃 。 


- errors: 发 生 错误 包 的 数量 ， 一 般 是 由 网 络 质 量 问题 引起 的 。 
. drops; 包 被 丢弃 的 数量 ， 一 般 是 由 内 存 不 足 引起 的 。 
:ovettuns: 由 于 来 不 及 处 理 而 导致 需要 重 传 的 包 。 


- retransmitted: 重 传 收 到 的 包 ， 一 般 是 上 面 三 个 的 和 。 


4. 网 卡 Running Queue Length 


Running Queue Length 是 指 网 卡 的 运行 队列 长 度 ， 反 映 网 卡 是 否 可 以 有 效 地 处 理 输入 业务 。Linux 下 似乎 没有 原生 的 监视 工具 ， 在 AIX 下 可 以 
用 netstat-v 命 令 来 查看 当前 运行 的 队列 长 度 。 


主机 网 络 的 性 能 统计 可 以 以 fconfig 的 统计 信息 为 主 ，netstat 和 sar 的 信息 为 辅 来 完成 。 


9.8 几 个 网 络 子 系统 资源 弟 见 问题 的 讨论 


98.1 系统 中 总 是 有 SQL*Net message from client 事 件 


查看 Oracle 系 统 时 ， 你 可 能 会 发 现 几乎 90% 的 会 话 处 于 SQL*Net message from client 事 件 的 等 待 中 ， 这 是 否 意味 着 都 在 等 待 客 户 端 响应 或 者 
客户 端的 响应 速度 慢 呢 ? 显然 不 是 ，v$session_wait 是 从 CPU 的 观点 来 看 待 等 待 事件 的 。SQL*Net message from client 事 件 意味 着 两 件 事 : 在 做 
CPU 处 理 或 处 于 空闲 状态 。 


大 量 的 SQL*Net message from client 并 不 意味 着 网 络 传输 速度 慢 ， 但 通过 进一步 分 析 ， 特 别 是 与 SQL*Net message to client 的 结合 ， 可 以 
从 中 发 现 是 否 存 在 网 络 速度 慢 的 问题 。 


SQL*Net message to client 和 SQL*Net message to dblink 这 两 个 事件 表示 数据 放 入 网 络 缓存 的 时 间 ， 也 就 是 send Buffer 的 时 间 ， 因 此 它 
们 可 用 于 了 解 网 络 情况 。 如 果 该 统计 不 等 于 0， 则 意味 着 网 络 过 载 ， 来 不 及 处 理 相 关 的 网 络 数据 信息 。 要 注意 ，SQL*Net message to client 并 不 包 
含 真正 的 网 络 传输 时 间 。 


SQL*Net message from client 反 映 了 Oracle 等 待 客户 端 响应 的 时 间 ， 无 论 是 主动 等 待 还 是 被 动 等 待 。 我 们 可 以 从 事件 的 柱状 图 统计 中 找到 主 
动 等 待 ， 主 动 等 待 事件 响应 过 长 意味 着 客户 端 或 网 络 处 理 响 应 缓慢 。 一 般 而 言 ， 在 正常 业务 周期 中 ， 数 量 明显 占 绝 大 部 分 的 基本 为 业务 运行 的 立即 
响应 ， 大 都 可 以 和 客户 端 响应 (包括 网 络 时 间 ) ， 这 样 就 大 致 反 映 出 了 Oracle 网 络 的 RTT 响 应 ， 代 码 如 图 9-25 所 示 。 


SQL» select * from v$event histogram where event-'SQL*Net message from client'; 
WAIT TIME MILLI WAIT COUNT LAST UPDATE TIME 


SQL*Net message client 28-10H -14 .16.53.519415 

SQL*Net message client 28-10H -14 . .51.386143 

SQL*Net message client 28-10H -14 . .48.298337 

SQL*Net message client 28-10H -14 ° .48.291491 

SQL*Net message client 28-10H -14 . .53.517425 

SQL*Net message client 28-10 H-14 .07.13.474904 

SQL*Net message client 28-10H -14 . .55.615337 

SQL*Net message client 28-10H -14 . .45.216982 

SQL*Net message client 28-10 月 -14 .07.24.832337 

SQL*Net message client 28-10H-14 .16.42.271315 

SQL*Net message client 28-10H-14 .15.55.574026 

SQL*Net message client 28-10H -14 . .53.592807 

SQL*Net message client 28-10H-14 s a .876297 下 午 +08:00 
SQL*Net message client 28-10 月 -14 04.16.04.954598 下 午 +08:00 
SQL*Net message client 28-10 月 -14 04.16.53.505903 下 午 +08:00 
SQL*Net message client 28-10 月 -14 04.16.41.860610 FÆ +08:00 
SQL*Net message client 28-10H -14 .16.07.879584 :00 
SQL*Net message clíent 131072 28-10H -14 . . .814616 

SQL*Net message client 262144 

SQL*Net message client 524288 28-10 H -14 * .51.367942 

WAIT TIME MILLI LAST UPDATE TIME 


SQL*Net message 1048576 28-10-14 04.06.38.068197 
21 rows selected 


图 9-25 SQL*Net message from client 的 代码 


9.9 ”网 络 子 系统 资源 优化 的 目标 和 道路 


9.9.1 ”网 络 资源 问题 的 场景 和 优化 道路 


几乎 所 有 的 网 络 资 源 问题 都 是 由 以 下 四 个 原因 造成 的 。 


“ 网 络 系统 故障 ， 包 含 硬 故 障 、 软 故障 和 配置 故障 。 


“ 网 络 系统 全 局 承载 过 大 的 输入 /输出 压力 ， 导 致 性 能 不 佳 。 


“ 存储 系统 局 部 承载 过 大 的 输入 /输出 压力 ， 寻 致 性 能 不 佳 。 
:网络 参 数 设 置 不 当 ， 引 起 吞吐 量 不 足 。 


在 明确 了 网 络 资源 问题 后 ， 只 要 进行 针对 性 优化 即 可 ， 措 施 当然 也 非常 简单 ， 图 9-27 展 示 了 网 络 性 能 问题 的 优化 思路 。 


分 布 网 
pop EÀ o2 n ie 
络 流量 网 络 问 是 


降低 网 
络 流量 


增加 网 优化 网 确保 网 络 
Lea 络 配置 Jens 


图 9-27 网 络 问题 的 优化 思路 


: 明确 网 络 故障 ， 修 正 配置 或 修复 存储 。 


. 降低 网 络 系统 的 全 局 输入 压力 。 
:分布 网 络 系统 压力 ， 使 每 个 网 络 设备 处 于 合理 范畴。 


: 优化 网 络 参 数 设 置 ， 充 分 发 挥 硬件 系统 效能 。 


9.10 网络 子 系统 资源 优化 案例 


1.Oracle RAC 的 全 表 扫 描 导 致 网 络 流量 剧 增 


某 运营 商 的 业务 系统 响应 缓慢 ， 检 查 业 务 发 现 大 量 的 gc cr multi block request， 同 时 RAC 通 信 节 点 之 间 的 吞吐 量 超过 80MB。 虽 然 只 有 几 万 
行 的 小 型 表格 发 生 全 表 扫 描 ， 在 本 地 业务 中 不 会 引起 任何 障碍 。 但 若 发 生 在 Oracle RAC 中 ， 持 续 的 网 络 通信 就 发 生 会 导致 网 络 拥塞 ， 从 而 使 运行 
性 能 下 降 。 通 过 简单 地 增加 索引 ， 使 之 通过 索引 访问 ，RAC Cache Fusion 导 致 网 络 通信 堵塞 的 情况 大 幅度 改善 。 


2.Oracle DRM 动 态 复制 导致 网 络 流量 剧 增 


某 运营 商业 务 发 现 系统 RAC Cache fusion 涉 及 的 网 络 通 信 达 到 100MB，Ims 进 程 CPU 消耗 很 高 ， 局 部 业务 响应 延迟 。 检 查 系统 ， 发 现 DRM 活 
动 非常 活跃 ， 为 RAC 通 信 贡 献 了 相当 一 部 分 流量 。 考 虑 到 DRM 的 众多 bug， 简 单 关 闭 DRM 以 恢复 业务 。 


3. 广 域 链 路 的 array fetch 和 引 警 转换 


某 书城 的 广 域 链 路 数据 传输 性 能 无 法 令 人 满意 ， 主 要 是 大 规模 获取 数据 的 广 域 链 路 RTT 比 较 低 引起 的 。 但 是 和 业务 程序 也 有 一 定 的 关系 ， 通 过 
array fetch 技 术 减 少 网 络 来 回 次 数 使 性 能 有 一 定 改善 ， 但 依然 没有 到 可 以 接受 的 地 步 。 由 于 客户 端的 版 本 比较 老 ， 更 新 了 dephi 的 oci 库 使 引擎 转换 
效率 提高 ， 传 输 速 度 基本 可 以 接受 。 


4.DNS 服 务 路 由 错误 导致 性 能 大 幅 下 降 


某 电力 公司 内 部 机 器 访问 数据 库 都 非常 快 ， 但 是 外 部 机 器 访问 很 慢 ， 甚 至 无 法 进行 连接 。 显 然 问题 在 网 络 ， 通 过 traceroute 跟 踪 发 现 ， 网 络 链 
路 不 是 理想 状态 。 所 有 链 路 都 到 一 个 外 网 链 路 转 了 个 圈 。 检 查 网 络 配 置 ， 发 现 意外 地 启用 了 DNS 服 务 ， 关 闭 DNS 服 务 恢复 正常 。 


5. 网 络 交 换 机 的 大 型 包 交换 故障 导致 Oracle RAC 经 常 被 剔 出 


某 运营 商 的 Oracle RAC 系 统 在 运行 过 程 中 经 常 性 地 出 现 某 节点 被 剔 出 的 情况 ，oswatch 的 性 能 历史 数据 一 直 处 于 正常 状态 。 因 Oracle RACH 
点 被 剔除 ， 想 到 可 能 是 网 络 中 断 引 起 的 ， 检 查 oswatch 并 未 发 现 错误 ， 再 次 判断 可 能 是 交换 机 在 大 包 通 信和 处理 上 存在 问题 。 通 过 ping 8k 大 包 方 式 
爹 查 通信 ， 果 然 发 现存 在 比较 严重 的 丢 包 现象 。 移 交 给 网 络 三 商 ， 重 新 启动 网 络 交换 机 恢复 业务 。 由 于 Oracle 通 信 在 很 多 时 候 需 要 比较 大 的 报 文 传 
输 ， 因 此 ， 在 这 个 时 候 ， 基 础 网 络 通信 正常 并 不 意味 着 Oracle 通 信 正 常 。 


6.vpn 链 路 的 包 限 制导 致 连接 数据 库 失败 


某 公交 自行 车 客户 的 vpn 链 路 tnsping 正 常 ， 但 是 数据 库 连 接 失败 。 除 了 vpn 链 路 之 外 的 其 他 链 路 都 正常 ， 显 然 问题 在 vpn 链 路 本 身 。 通 过 
sql*net client 跟 踪 发 现 ， 在 达到 1664 字 节 的 时 候 网 络 无 法 通信 ， 处 于 挂 起 状态 ， 检 查 vpn 设 置 ， 发 现 是 包 大 小 的 设置 有 问题 ， 修 改 配置 恢复 正常 。 
具体 详 见 周亮 的 《Oracle DBA 实 战 攻略 》 一 书 。 


7. 大 量 time_wait 的 tcp 链 接 导 致 socket 不 足 


某 运 营 商 报告 每 周 几乎 总 有 几 个 时 段 数据 库 响 应 特别 慢 ， 甚 至 都 没有 响应 ， 有 时 候 还 会 报告 错误 。 检 查 数据 库 ， 几 乎 处 于 空 载 状 态 ， 检 查 
listener 及 tcp 链 路 ， 发 现 频繁 的 listener 连 接 和 time_wait 链 路 。 从 现象 上 看 ， 业 务 应 该 是 以 短 连 接 方式 访问 数据 库 ， 注 定 是 不 可 扩充 的 访问 模式 。 
咨询 开发 商 之 后 ， 确 认 是 以 短 连接 方式 访问 数据 库 的 ， 由 于 listener 本 身 的 不 可 扩展 性 ， 因 此 ， 并 非 降低 了 time_wait 的 链 路 就 可 以 解决 性 能 问题 ， 
而 需要 开发 商 修订 短 连接 方式 为 连接 池 模 式 来 访问 数据 库 。 


8. 控 制 文件 自动 备份 到 NFS 引 起 系统 挂 起 


某 运营 商 系统 出 现 间歇 性 的 挂 起 ， 且 挂 起 时 间 比 较 长 。 从 数据 库 现场 来 看 ，ckpt 进 程 、|gwr 进 程 等 都 在 等 待 CF 锁 ， 而 抓 住 CF 锁 的 操作 为 自动 
化 的 控制 文件 备份 ， 该 控制 文件 备份 的 目标 为 一 个 NFS 文 件 系 统 。NFs 文 件 系 统 的 挂 载 参数 属于 推荐 参数 ， 手 工 备份 并 不 会 发 生 错误 ， 自 动 化 备份 
也 是 偶尔 会 发 生 挂 起 现象 。 考 虑 到 控制 文件 规模 比较 小 ， 控 制 文件 备份 目标 从 NFS 文 件 系 统 迁 出 到 本 地 文件 系统 。 在 实践 中 ， 标 准 化 的 NFS 作 为 数 
据 库 类 载体 的 问题 相对 比较 多 ， 基 本 表现 为 数据 库 挂 起 ， 也 有 些 比 较 容 易 出 现 逻 辑 腐 败 。 即 使 是 在 NAS 设 备 中 ， 虽 然 都 经 过 Oracle 认 证 ,但 从 感知 
来 讲 ， 似 乎 逻辑 腐败 出 现 的 概率 相对 比较 高 。 也 许 并 不 是 NAS 的 问题 ， 而 是 NAS 设 备 相 对 比较 低 端 ， 而 作为 比较 对 象 的 SAN 设 备 相 对 比较 高 端 ， 
此 逻辑 腐败 出 现 的 概率 会 比较 高 。 


9. 网 卡 问题 导致 网 络 性 能 不 佳 


某 运 莒 商 的 日 志 同 步 复 制 出 现 延 迟 ， 检 查 发 现 网 络 传输 性 能 不 佳 ， 只 有 20MB 左 右 的 传输 能 力 ， 与 之 前 80MB 左 右 的 吞吐 量 相 比 ， 有 很 大 差 
异 。 检 查 网 络 配置 和 主机 内 人 存 ， 处 于 相对 合理 的 范畴 。 在 网 络 配置 合理 的 情况 下 ， 只 有 主机 内 存 不 足 才 会 出 现 网 络 传输 能 力 不 足 的 问题 。 而 现在 主 
机 内 存 自 由 空间 充足 ， 业 务 运 行 也 很 正常 。 因 此 ， 判 断 是 网 卡 出 现 了 性 能 故障 ， 换 上 新 网 卡 ， 重 启 后 网 络 性 能 恢复 。 网 卡 导 致 的 问题 往往 比较 奇 
怪 ， 比 如 某 运 营 商 的 ATM 网 卡 几 乎 提供 的 所 有 服务 都 正常 ， 但 是 无 法 使 某 节 点 加 入 RAC 集 群 ， 将 其 更 换 为 以 太 网 卡 就 修复 了 问题 。 
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某 运 营 商 的 EAI 系统 在 业务 处 理 逐 渐 加 大 之 后 表现 出 大 量 的 ITL lock， 从 最 初 的 每 周一 次 到 后 来 的 每 日 一 次 ，ITL lock 导 致 业务 系统 hang， 被 迫 
重新 启动 以 恢复 业务 。 各 路 人 马 (都 是 顶级 国际 厂商 ) 进行 了 会 诊 和 调整 ， 但 几乎 没有 任何 效果 。 以 前 和 该 客户 具有 紧密 的 关系 ， 笔 者 某 天 下 午 也 
过 去 帮忙 了 。 笔 者 简单 看 了 下 ， 即 使 在 所 谓 的 还 可 以 的 状态 下 都 有 大 量 ITL lock，DBA 已 经 增 大 了 maxtrans， 但 效果 不 大 。 看 了 看 系统 ， 了 解 了 业 
务 系统 的 基本 公用 后 ， 笔 者 基本 断定 ITL lock 和 EAI 系统 没有 太 大 关系 。 召 来 相关 人 员 解 释 业 务 流程 的 具体 流转 后 ， 笔 者 的 建议 很 简单 ， 在 EAI 业务 
流转 到 其 他 业务 系统 之 前 增加 commit 语 句 。EAI 是 一 个 极为 简单 的 应 用 整合 系统 ， 接 受 指令 记录 日 志 并 交 由 weblogic 工 作 流 ， 通 过 http 调 用 siebel 
CRM 和 CSG 计 费 的 相关 业务 。 在 本 案例 中 ， 随 着 业务 量 的 变 大 ，siebel CRM 和 CSG 计 费 系 统 效率 有 所 降低 ， 导 致 EAI 锁定 的 时 间 变 长 ， 就 产生 了 大 
量 的 ITL lock。 


在 全 省 性 的 运营 商业 务 设计 中 ， 系 统 之 间 的 全 同步 设计 是 典型 的 架构 设计 错误 ， 必然 导 致 其 吞吐 量 有 限 效率 低下 。 如 果 需 要 高 业务 吞吐 量 ， 异 
步 设计 是 一 个 基本 准则 。 只 有 在 低 吞 吐 量 系统 中 ， 为 了 使 业务 简单 才 会 考虑 全 同步 设计 。 


事实 上 有 更 好 的 处 理 方式 来 解决 上 面 的 ITL lock 问 题 。 将 表格 设计 成 分 区 表 ， 分 成 32 或 64 个 分 区 ， 当 然 还 可 以 更 大 ， 依 据 处 理 进程 id 的 余数 进 
行 分 区 ， 使 各 自 进程 的 操作 落 在 各 自分 区 中 ， 进 程 之 间 的 冲突 自然 就 变 少 了 。 
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10.1 简单 案例 分 享 


某 运 营 商 的 EAI 系统 在 业务 处 理 逐 渐 加 大 之 后 表现 出 大 量 的 ITL lock， 从 最 初 的 每 周一 次 到 后 来 的 每 日 一 次 ，ITL lock 导 致 业务 系统 hang， 被 迫 
重新 启动 以 恢复 业务 。 各 路 人 马 (都 是 顶级 国际 厂商 ) 进行 了 会 诊 和 调整 ， 但 几乎 没有 任何 效果 。 以 前 和 该 客户 具有 紧密 的 关系 ， 笔 者 某 天 下 午 也 
过 去 帮忙 了 。 笔 者 简单 看 了 下 ， 即 使 在 所 谓 的 还 可 以 的 状态 下 都 有 大 量 ITL lock，DBA 已 经 增 大 了 maxtrans， 但 效果 不 大 。 看 了 看 系统 ， 了 解 了 业 
务 系统 的 基本 公用 后 ， 笔 者 基本 断定 ITL lock 和 EAI 系统 没有 太 大 关系 。 召 来 相关 人 员 解 释 业 务 流程 的 具体 流转 后 ， 笔 者 的 建议 很 简单 ， 在 EAI 业务 
流转 到 其 他 业务 系统 之 前 增加 commit 语 句 。EAI 是 一 个 极为 简单 的 应 用 整合 系统 ， 接 受 指 令 记录 日 志 并 交 由 weblogic 工 作 流 ， 通 过 http 调 用 siebel 
CRM 和 CSG 计 费 的 相关 业务 。 在 本 案例 中 ， 随 着 业务 量 的 变 大 ，siebel CRM 和 CSG 计 费 系统 效率 有 所 降低 ， 导 致 EAl 锁 定 的 时 间 变 长 ， 就 产生 了 大 


量 的 ITL lock, 


在 全 省 性 的 运营 商业 务 设计 中 ， 系 统 之 间 的 全 同步 设计 是 典型 的 架构 设计 错误 ， 必 然 导 致 其 吞吐 量 有 限 效率 低下 。 如 果 需 要 高 业务 吞吐 量 ， 异 
步 设计 是 一 个 基本 准则 。 只 有 在 低 吞 吐 量 系统 中 ， 为 了 使 业务 简单 才 会 考虑 全 同步 设计 。 


事实 上 有 更 好 的 处 理 方式 来 解决 上 面 的 ITL lock 问 题 。 将 表格 设计 成 分 区 表 ， 分 成 32 或 64 个 分 区 ， 当 然 还 可 以 更 大 ， 依 据 处 理 进程 id 的 余数 进 
行 分 区 ， 使 各 自 进程 的 操作 落 在 各 自分 区 中 ， 进 程 之 间 的 冲突 自然 就 变 少 了 。 


10.2 ”并 友 性 控制 和 队列 锁 


队列 锁 是 Oracle 数 据 库 实 现 并 发 性 和 一 致 性 控制 的 基本 手段 。 队 列 锁 采 用 FIFO 实 现 ， 主 要 作用 在 持久 性 对 象 上 的 一 致 性 访问 控制 ， 部 分 非 持 
久 性 对 象 也 采用 队列 锁 实 现 ， 比 如 row cache lock、library cache lock 等 。 


10.3 ”事务 锁 


事务 锁 是 Oracle 保 证 数据 一 致 性 的 最 主要 的 锁 类 型 ， 平 常 所 讲 的 锁 主 要 就 是 指 事务 锁 。TX lock 用 于 保护 表格 中 某 行 的 一 致 性 访问 ， 系 统 中 TX 
锁 同 时 存在 的 数量 受 参数 transactions 的 限制 。 这 里 读者 可 能 会 存在 疑问 ， 数 据 库 中 表格 有 几 王 万 、 几 亿 甚 至 几 十 亿 行 ， 但 是 参数 transactions 只 
有 几 百 到 几 干 的 范畴 ， 那 如 何 利用 TX lock 来 保证 表格 中 行 的 数据 一 致 性 呢 ? 看 看 下 面 的 示例 脚本 ， 每 次 更 新 一 行 ， 总 共 更 新 10 行 。 这 些 不 同 的 10 
行 都 被 相同 的 TX lock 所 保护 。 


-- Created on 2014/11/2 by LIUZL 
declare 
-- Local variables here 
i integer; 
cursor c is select * from v$lock where sid-sys context('userenv','sid') and type-'TX'; 
begin 
-- Test statements here 
for i in 1http://www.hzcourse.com/resource/readBook?path-/openresources/teach ebook/uncompressed/15574/OEBPS/Text/..10 loop 
delete from tobj where rownum«2; 
for i in c loop 


dbms output.put line(i.addr||';'|li.kaddr||';'|li.idl|]|]'.'|li.id2|]|';'|l|i.lmode||';'|li.request); 
exit when c$notfoung; 
end loop; 
end loop; 
rollback; 
end; 
脚本 的 输出 如 下 : 
000007FF15744320;000007FF15744398; 524290.141720;6;0 
000007FF15744320; 000007FF15744398; 524290.141720;6;0 
000007FF15744320;000007FF15744398; 524290.141720;6;0 
000007FF15744320;000007FF15744398; 524290.141720; 6;0 
000007FF15744320;000007FF15744398; 524290.141720; 6;0 
000007FF15744320;000007FF15744398; 524290.141720;6;0 
000007FF15744320;000007FF15744398; 524290.141720;6;0 
000007FF15744320;000007FF15744398; 524290.141720;6;0 
000007FF15744320; 000007FF15744398; 524290.141720;6;0 
000007FF15744320;000007FF15744398; 524290.141720; 6;0 


10.4 TM 锁 


TM$ (TM Lock) 又 被 称 为 DML 锁 ， 用 于 实现 对 表格 对 象 的 一 致 性 访问 。 从 v$enqueue_statistics 中 可 以 查询 关于 TM lock 的 简单 说 明 ， 如 
图 10-65 所 示 。 


SQL» select eq name,req reason,REQ DESCRIPTION from v$enqueue statistics where eq type-'TM'; 
REQ DESCRIPTION 


contention Synchronizes accesses to an object 


图 10-65  v$enqueue. statistic P X F TM lock 的 简单 说 明 


记录 存储 在 表格 中 ， 是 为 了 避免 在 访问 数据 时 对 象 发 生变 更 ， 任 何 需要 TX 锁 的 操作 都 需要 在 表格 上 加 锁 。 大 部 分 情况 下 增加 的 是 模式 为 3 的 RX 
锁 ， 有 时 候 会 在 请 求 时 要 求 % 锁 ， 在 获得 之 后 降级 为 RX 锁 ， 如 图 10-66 所 示 。 


SQL» select sid from v$mystat where rownum«2; 


SQL» delete from d2 where rownum«2; 
1 row deleted 


SQL» select * from v$lock where sid-771; 
SID TYPE 


000007FF179FOF98 000007FF179FOFFO 
000000001BEA62AO 000000001BEA6300 
000000001BEA62AO 000000001BEA6300 
000007FF15743920 000007FF15743998 138592 


图 10-66 ”更 新 操作 获得 TM lock 


10.5 ”sequence 相 关 的 锁 


作为 Oracle 内 置 的 一 种 高 效 序列 发 生 器 的 实现 ，sequence 在 减少 了 TX lock 冲 突 的 同时 ， 自 身 也 产生 了 问题 。sequence 相 关 的 锁定 问题 是 
Oracle 性 能 优化 中 相对 重要 的 一 个 篇 章 ，sequence 相 关 的 性 能 问题 也 比较 多 见 。 本 章 仅 描述 队列 锁 问 题 ，sequence 相 关 的 latch 在 latch 章 节 介 
gn 


-Ho 
sequence 相 关 的 主要 锁定 问题 为 SQ lock, row cache lock 和 DFS lock handle (SV lock) 。 
sequence 的 基本 结构 如 下 。 


数据 字典 表 SEQ$，SEQ$ 在 row cache 中 映射 dc_sequences、sequence cache，Oracle 为 了 加 速 数据 字典 处 理 ， 会 把 SEQ$ 缓 存 到 row 
cache 中 ， 而 Sequence.nextval 导 致 的 9EQ$ 则 构成 自 包含 事务 ， 不 可 回 滚 。 


10.6 HW lock 和 ST lock 


HW lock 和 ST lock 都 和 空间 管理 有 关 ， 在 空间 频繁 扩展 和 收回 的 业务 中 ，HW lock 和 ST lock 可 能 会 经 常 看 到 。ST lock 在 表 空 间 数据 字典 管理 
时 代 是 主要 的 锁 冲 突 问题 ， 进 入 位 图 管理 时 代 ，ST lock 已 经 比较 少见 。 而 HW 锁 在 日 志 型 应 用 中 是 一 种 比较 常见 的 锁 冲 突 类 型 。Oracle 自 身 对 ST 
和 HW 锁 的 描述 如 图 10-108 所 示 。 


SQL» select eq name,eq type,req description from vSenqueue statistics where eq type in('ST','HW'); 
EQ TYPE REQ DESCRIPTION 


Space Transaction Synchronizes space management activities in dictionary-manag 
ed tablespaces 

Segment High Water Mark Lock used to broker the high water mark during parallel inse 
rts 


图 10-108 ST lock feHW lock 的 描述 


从 描述 来 看 ， 在 位 图 管理 时 代 ，ST lock 已 经 消失 了 。 不 管 它 是否 消 失 ， 在 位 图 管理 时 代 几 乎 没有 遭遇 过 ST lock， 这 里 就 不 再 对 ST lock 进 行 前 
述 ， 仅 介绍 HW lock。 


10.7 CFlock 


CF lock 作 用 在 控制 文件 上 ， 任 何 控制 文件 的 读 和 写 都 需要 CF lock 参 与 。 显 而 易 见 ， 控 制 文件 的 访问 需要 MO 操作 ， 也 就 是 说 ，CF lock 的 持 有 
时 间 是 比较 长 的 。 过 多 进程 过 度 频 繁 地 访问 CF lock， 必 然 会 引起 全 局 业务 系统 的 瘫 病 。 另 外 ，CF lock 作 用 在 控制 文件 上 ， 磁 盘 I/O 系 统 锁 导 致 的 
各 种 问题 都 会 引起 CF lock 的 长 期 持 有 ， 比 如 笔者 多 次 遇 到 I/O 阻 塞 无 响应 而 导致 数据 库 实例 宕 机 的 问题 。 


10.8 US lock 


US lock 作用 于 undo segment， 是 undo segment 的 对 象 锁 。Oracle 在 自动 管理 的 undo segment 中 ， 总 是 优先 考虑 每 个 事务 具有 独立 的 
undo segment， 同 时 为 了 更 高 的 undo segment 管 理 效率 ， 会 经 常 执行 undo segment 的 offline 操 作 以 匹配 事务 规模 ， 在 需要 undo segment 的 
时 候 执行 online。 基 于 同样 的 目的 ，smon 进 程 会 定期 对 undo segment 执 行 shrink。 除 offline、online 及 shrink 外 ， 实 际 中 一 个 重要 的 US lock 获 
得 场景 就 是 undo segment retention 的 自动 管理 。 回 滚 段 自动 管理 带 来 了 便利 性 ， 但 在 某 些 高 并 发 性 的 业务 中 ， 特 别 是 在 事务 众多 的 系统 中 会 造 
成 频繁 地 undo segment retention 问 题 ， 频 繁 地 自动 offline 和 online， 会 造成 用 户 进程 等 待 US lock, 


另外 需要 注意 的 是 ， 在 验证 中 ，undo segment extends 并 不 需要 US lock 参 数 ， 而 是 需要 latch: undo global data 的 参与 。latch: undo 
global data 将 在 后 面 讲述 ， 这 里 不 会 涉及 。 


10.9 RO lock 


RO lock 主 要 用 于 drop 或 truncate 后 在 buffer cache 中 进行 对 象 清理 。 为 了 维护 drop 或 truncate 操 作 的 一 致 性 ， 需 要 发 起 一 个 local 
checkpoint 操 作 ， 把 涉及 的 buffer cache block 写 回 磁盘 。 为 了 使 其 效率 更 高 ，Oracle 通 过 fast object reuse 机 制 来 实现 buffer cache block 的 快 
速 重用 。 不 管 是 在 fast object reuse 过 程 中 还 是 在 flush buffer cache 过 程 中 都 需要 RO 锁 。 


显然 ， 表 格 数据 在 buffer cache 中 的 数据 块 越 多 ，drop table 或 truncate table 的 速度 就 越 慢 ， 需 要 获取 的 RO 锁 就 越 多 ， 如 图 10-130 所 示 。 


SQL» select * from vS$enqueue stat where eq type-'RO'; 
INST ID EQ TYPE TOTAL REQ# TOTAL WAIT# SUCC REQ# FAILED REQ# CUM WAIT TIME 


SQL» truncate table tobj; 
Table truncated 


SQL» select * from vSenqueue stat where eq type-'RO'; 
INST ID EQ TYPE TOTAL REQ# TOTAL WAIT# SUCC REQ# FAILED REQ# CUM WAIT TIME 


图 10-130 ”RO 锁 和 truncate 操 作 


Fast Object reuse 就 是 在 执行 truncate 或 者 drop 操 作 的 时 候 不 对 truncate 或 者 drop 涉 及 的 buffer cache 对 象 执 行 清理 操作 ， 而 是 交 由 smon 
进程 慢 慢 清理 。 图 10-131 所 示 的 测试 清楚 地 展示 了 这 种 状况 。 


SQL» select count(*) from v$bh where objd-776194; 
COUNT (*) 


SQL» truncate table tobj; 
Table truncated 


SQL» 
COUNT (*) 


SQL» drop table tobj; 
Table dropped 


SQL» select count(*) from VSbh where objd-76194; 
COUNT (*) 


图 10-131 truncate 涉 及 对 象 的 缓慢 清理 过 程 


10.10 ”队列 锁 运 行 性 能 的 衡量 


10.10.1 ”队列 锁 运 行 性 能 的 衡量 指标 


队列 锁 资 源 的 性 能 主要 通过 以 下 指标 来 衡量 。 
(1) 总 请 求 数 (total requests per second) 
total requests pre second: 锁 资 源 的 总 请 求 次 数 ， 该 指标 用 于 衡量 锁 资源 的 繁忙 程度 。 


(2) 总 等 待 数 (total waits per second) 和 锁 等 待 比例 (wait request ratio) 


total waits per second: 锁 资源 的 总 等 待 次 数 ， 该 指标 用 于 衡量 锁 冲 突 的 程度 ， 在 并 发 性 系统 中 ， 与 total_requests 具 有 一 致 性 关系 。 


wait request ratio: 锁 等 待 比例 ， 计 算 公 式 为 wait_requst_ratio=total wait per second/total requests per second, 
(3) 成 功 请 求 数 (succ requests per second) 和 成 功 请 求 率 (lock request ratio) 

succ requests: 成 功 获得 锁 的 次 数 。 

lock request ratio: 成 功 获得 锁 资 源 的 比例 ， 计 算 公式 为 succ request per second/total requests per second, 
(4) 失败 请 求 数 (failed requests) 

failed requests: 锁 请 求 失败 的 次 数 ， 包 含 死 锁 的 次 数 。 

(5) 死 锁 发 生 次 数 (deadlock requests) 

deadlock requests: 死 锁 发 生 的 次 数 。 

(6) 平均 响应 时 间 (avgresponsetime) 

avgresponsetime: 平均 锁 等 待 和 持 有 时 间 ， 该 指标 很 有 用 ， 但 是 目前 无 法 获得 。 

(7) 平均 等 待 时 间 (avgWaitTime) 

avgWaitTime: 平均 锁 等 待 时 间 。 

(8) 最 大 等 待 时 间 (maxWaitTime) 


maxWaitTime: 最 长 锁 等 待 时 间 ， 锁 性 能 事故 的 发 布 往往 不 是 由 平均 等 待 决定 的 ， 而 是 由 最 大 等 待 决定 的 。 


10.11 队列 锁 资 源 优化 的 目标 和 道路 


队列 锁 属 于 并 发 性 控制 资源 ， 并 发 性 控制 资源 就 是 只 有 当 并 发 业务 多 时 才 有 可 能 发 生 队 列 锁 资 源 问题 。 


假设 200 个 用 户 共同 更 新 某 一 行 ， 更 新 一 行 的 事务 需要 100ms。 大 家 都 知道 100ms 再 正常 不 过 。200 个 transaction 以 队列 形式 排队 ， 每 个 处 理 
100ms， 到 达 第 200 个 transation 时 ， 他 的 事务 处 理 时 间 为 200*100ms=20000ms=20s。 这 下 问题 来 了 ，20s 的 响应 几乎 在 所 有 的 oltp 系 统 都 无 法 
接受 。 当 然 这 是 极端 情况 ， 但 性 能 问题 都 是 在 极端 情况 下 发 生 的 。 


可 能 有 人 会 说 ， 怎 么 可 能 会 出 现 这 样 的 业务 逻辑 呢 ! 是 的 ， 这 样 的 业务 逻辑 不 存在 。 但 是 以 下 的 业务 逻辑 是 普遍 存在 的 ， 否 则 就 不 存在 锁定 问 
"e 


pm 


2~3 个 transaction 更 新 相同 的 行 ， 每 2~ 3 个 transaction 形 成 相互 依赖 。 事 实 上 ， 这 种 情况 的 200 个 transaction 并 发 和 200 个 transaction 作 用 
于 相同 行 的 transaction 并 发 没有 任何 区 别 。 业 务 有 时 确实 需要 这 样 操 作 ， 这 也 是 Oracle 为 什么 会 有 处 理 上 限 的 根本 原因 之 一 。 


队列 锁 资 源 不 同 于 简单 的 硬件 资源 ， 不 同 的 队列 锁 有 其 不 同 的 产生 场景 ， 但 总 体 而 言 ， 所 有 队列 锁 的 处 理 方式 都 是 一 致 的 。 基 本 而 言 ， 队 列 锁 
资源 的 问题 主要 由 以 下 几 个 因素 构成 。 


: 业务 压力 导致 的 巨 量 队列 锁 资源 需求 。 


业务 不 当 导 致 过 多 持 有 队列 锁 。 


“ 持 有 队列 锁 的 时 间 过 长 。 


“ 缺乏 事务 失败 思维 导致 事务 规模 过 大 。 


- 调度 和 运 维 不 当 导 致 队列 锁 长 期 持 有 。 


“ 拥有 队列 锁 资 源 的 进程 处 于 僵 死 或 不 活动 状态 。 


10.12 ”队列 锁 资 源 优化 案例 


1. 超 级 事务 回 滚 导 致 队列 锁 资 源 和 smon 资 源 缺 乏 


某 运 营 商 的 账 务 系统 在 某 时 刻 出 现 业 务 系统 性 能 下 降 ， 简 单 检查 为 大 量 的 TX 锁 等 待 ， 同 时 发 现 smon 在 进行 大 型 事务 回 滚 。 该 业务 锁 等 待 的 原 
因 非 常 简单 ， 手 工 处 理 的 批量 update 操 作 意外 被 中 止 ， 引 起 系统 回 滚 。 回 滚 操作 依赖 于 smon， 其 回 滚 的 速度 非常 缓慢 。 在 这 种 情况 下 ， 只 能 等 待 
回 滚 完成 ， 或 者 重新 启动 数据 库 加 速 回 滚 。 超 级 事务 失败 是 一 个 实践 中 普遍 存在 的 性 能 故障 ， 每 年 总 有 发 生 。 


2.select for update 锁 定 所 有 记录 


在 业务 运行 过 程 中 ， 某 张 主要 表格 发 生 大 规模 的 TX 锁 冲突 ， 导 致 业务 完全 挂 起 。 其 原因 非常 简单 ， 某 个 维护 人 员 通 过 PLSQL 发 起 了 一 个 select 
for update 操 作 ， 导 致 表格 大 量 的 行 被 锁定 。 


3.sequence cache 过 小 引起 数据 库 登 录 挂 起 


某 运 莒 商 实 时 计 费 系统 偶尔 会 出 现 session 挂 起 ， 所 有 的 Session 登录 几 乎 完全 被 挂 起， 而 运行 中 的 session 则 可 以 正常 操作 。 检 查 systemdump 
发 现 ， 所 有 的 挂 起 session 都 在 等 待 audses$ 的 sequence， 只 要 把 占有 的 SQ lock 的 sesssion 杀 掉 ， 所 有 登录 都 可 以 继续 。 检 查 audses$ 的 cache 为 
默认 的 20， 增 大 audses$ 的 cache 为 10000， 业 务 系统 再 也 没有 出 现 类 似 状 况 。 


4.SQ lock 和 US lock 冲 突 导 致 业务 系统 缓慢 


某 运营 商业 务 系统 突然 变 得 异常 缓慢 ， 大 量 的 SQ lock, US lock, row cache objects latch, undo global data latch 及 row cache lock 
W. SAA undo_autotune 可 恢复 业务 ， 但 是 其 根本 原因 是 新 上 线 的 某 业 务 中 包含 了 高 并 发 的 sequence， 其 cache 默 认为 20。 


5.rman 调 度 删 除 归档 日 志 导致 业务 短暂 挂 起 


某 医院 业务 系统 间歇 性 地 出 现 业务 停顿 5 秒 左右 ， 已 经 持续 了 一 些 时 间 。 检 查 之 后 ， 发 现 问题 源 于 无 法 获得 CF lock， 而 CF lock 被 rman 进 程 所 
持 有 。 修 改定 期 运行 rman 删 除 归档 日 志 为 操作 系统 删除 ， 问 题 得 以 解决 。 


6 控制 文件 自动 备份 到 NFS 引 起 系统 挂 起 


某 运 营 商 每 一 两 月 会 发 生 一 次 业务 系统 挂 起 ， 挂 起 时 表现 为 ckpt 进 程 等 待 CF lock。 检 查 错误 日 志 ， 发 现存 在 控制 文件 自动 备份 ， 而 且 自 动 备 
份 的 目标 为 NFS。 把 自动 备份 调度 到 本 地 磁盘 ， 然 后 通过 操作 系统 工具 复制 到 NFS， 故 障 完全 消失 。 


7.Oracle 错 误 引 发 dump redolog 导 致 ckpt 等 待 


某 运营 商业 务 系统 发 生 挂 起 ， 挂 起 时 间 大 约 为 5 分 钟 ， 挂 起 期 间 ckpit 等 待 CF lock。 检 查 系 统 发 现 挂 起 期 间 发 生 一 个 oracle 错 误 ， 该 错误 引起 了 
diag 进 程 执行 redo log dump， 该 dump 的 持续 时 间 大 约 5 分 钟 。 对 所 有 dump 文 件 大 小 进行 限制 ， 该 故障 后 续 再 次 发 生 ， 无 法 确认 是 否 该 处 理 有 
效 。 


8. 业 务 处 理 中 的 ddl 引 起 业务 稳定 性 不 足 


某 银行 在 一 个 业务 批 处 理 中 包含 truncate 语 句 ， 发 现 truncate 语 句 的 性 能 不 可 预 估 ， 有 时 候 很 快 ， 有 时 候 则 很 慢 。 建 议 进 行 循 环 分 区 以 替代 这 
个 需要 不 断 truncate 的 表格 ， 新 进入 的 数据 都 是 具有 时 间 序 列 的 数据 ， 该 业务 每 月 执行 一 次 。 以 月 份 除 以 3 的 余数 作为 分 区 键 ， 这 样 新 的 数据 自然 
就 落 入 了 自己 的 分 区 ， 在 业务 批 处 理 启动 之 前 或 其 他 运 维 空闲 时 段 对 过 期 数据 进行 truncate， 避 免 在 业务 周期 发 生 truncate。 人 循环 分 区 处 理 之 后 ， 
业务 批 处 理 运 行 稳定 可 靠 。 


第 11 章 ”资源 供给 : row cache lock 和 library cache lock 


某 运营 商 持续 出 现 library cache lock, library cache load lock 及 library cache latch 冲 突 ， 即 使 重新 启动 ， 也 只 在 最 初 略 有 缓解 ， 之 后 很 快 
就 会 继续 发 生 状 况 。 最 初 判断 是 因为 shared pool 不 足 引起 的 ， 持 续 观 察 shared pool， 发 现 自由 空间 在 迅速 碱 少 ， 当 减少 到 一 定 程度 之 后 出 现 大 量 
的 libray cache lock 和 library cache load lock。 在 此 过 程 中 ， 系 统 中 存在 大 量 的 hard parse， 增 加 cursor sharing 之 后 ， 该 问题 基本 消失 。 但 
是 ， 打 开 cursor sharing 之 后 导致 部 分 业务 不 可 继续 ， 无 法 启用 cursor sharing。 于 是 持续 监控 shared pool， 在 shared pool 达 到 立 值 后 进行 flush 
pool， 终 于 使 该 问题 得 到 控制 。 最 后 判断 此 为 Oracle bug， 因 Oracle 无 法 正确 处 理 shared pool 的 Iru 策 略 ， 等 待 Oracle patch 而 导致 。 后 续 补丁 
到 位 之 后 ， 打 上 补丁 ， 该 问题 消失 。 


第 11 章 ”资源 供给 : row cache lock 和 library cache lock 


11.1 简单 案例 分 享 


某 运营 商 持 续 出 现 library cache lock, library cache load lock 及 library cache latch 冲 突 ， 即 使 重新 启动 ， 也 只 在 最 初 略 有 缓解 ， 之 后 很 快 
就 会 继续 发 生 状 况 。 最 初 判断 是 因为 shared pool 不 足 引 起 的 ， 持 续 观 察 shared pool， 发 现 自由 空间 在 迅速 减少 ， 当 减少 到 一 定 程度 之 后 出 现 大 量 
的 libray cache lock 和 library cache load lock。 在 此 过 程 中 ， 系 统 中 存在 大 量 的 hard parse， 增 加 cursor sharing 之 后 ， 该 问题 基本 消失 。 但 
是 ， 打 开 cursor sharing 之 后 导致 部 分 业务 不 可 继续 ， 无 法 启用 cursor sharing。 于 是 持续 监控 shared pool， 在 shared pool 达 到 阅 值 后 进行 flush 
pool， 终 于 使 该 问题 得 到 控制 。 最 后 判断 此 为 Oracle bug， 因 Oracle 无 法 正确 处 理 shared poo 的 Iru 策 略 ， 等 待 Oracle patch 而 导致 。 后 续 补丁 
到 位 之 后 ， 打 上 补丁 ， 该 问题 消失 。 


11.2 row cache lock 和 ddl lock 


row cache 用 于 保存 数据 字典 的 缓冲 ， 而 row cache lock 则 是 对 数据 字典 做 出 变更 或 禁止 其 他 人 变更 时 ， 加 载 在 row cache obect 上 的 锁 。 我 
们 平常 所 讲 的 ddl 锁 事实 上 是 row cache lock 的 一 个 子 集 ， 因 此 ddl lock 必 然 会 涉及 row cache lock， 只 是 ddl lock 不 仅 包含 row cache lock， 还 
包含 library cache lock 等 其 他 enqueue 资 源 。 


11.3 library cache lock 


library cache lock 主 要 在 ddl 操 作 和 parse 操 作 过 程 中 产生 。 回 顾 前 面 章节 涉及 的 library cache 结 构 ， 如 图 11-13 所 示 。 
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Hash Bucket Object Handles 


Name 

Namespace 

Lock owners 

Lock waiters 

Pin owners 

Pin waiters 

Flags 

Heap 0 (Object Heap 0 (Object) 


图 11-13 library cache 结 构图 


library cache lock 就 产生 在 object handles 中 ， 在 object handles 链 中 object handle 的 增加 和 减少 都 需要 library cache lock 的 参与 。 和 
library cache lock 紧 密 相关 的 有 了 两 个 enqueue: library cache load lock 和 library cache pin, library cache load lock 的 作用 是 把 library cache 
object 加 载 到 library cache 中 ， 而 library cache pin 则 作用 在 library cache object handle 下 面 的 heap 上 。 关 于 这 三 个 enqueue 是 如 何 工作 的 ， 请 
参见 http://www.dbsnake.net/library-cache-lock-and-pin.html， 这 里 不 再 进行 描述 。 


11.4 row cache lock 和 和 library cache lock 运 行 性 能 的 衡量 


11.4.1 row cache lock 资 源 运行 性 能 的 衡量 指标 


row cache lock 锁 资源 的 性 能 ， 主 要 通过 以 下 指标 来 衡量 。 


(1) 总 更 新 数 (total modified per second) 
total modified per second: 数据 字典 被 更 新 的 次 数 ， 每 次 更 新 都 意味 着 一 次 exclusive row cache lock 的 占用 。 
(2) 总 刷新 数 (total flushed per second) 


total flushed per second: 由 于 row cache 对 象 交 换 需要 刷 出 row cache 的 次 数 ， 所 以 频繁 地 被 刷 出 意味 着 shared pool 不 足 ， 导 致 其 需要 再 
次 被 装载 。 


(3) 等 待 次 数 (wait count per second) 

wait count per second: 需要 等 待 获得 row cache lock 的 次 数 。 
(4) 平均 等 待 时 间 (avgWaitTime) 

avgWaitTime: 平均 锁 等 待 时 间 。 
(5) 最 大 等 待 时 间 (maxWaitTime) 


maxWaitTime: 最 长 锁 等 待 时 间 ， 锁 性 能 事故 的 发 布 往往 不 是 由 平均 等 待 决定 的 ， 而 是 由 最 大 等 待 决定 的 。 


11.5 row cache lock 锁 资源 优化 的 目标 和 道路 


row cache lock 锁 资源 主要 获得 的 场景 来 源 于 以 下 两 个 方面 。 
- 数据 字典 的 变化 。 


:tow cache object 首 次 装载 到 tow cache 和 重新 装载 到 tow cacheo 


11.6 library cache lock 锁 资源 的 目标 和 道路 


library cache lock 的 出 现场 景 几乎 和 row cache lock 完 全 一 样 ， 只 是 library cache lock 不 是 数据 字典 变化 ， 而 是 dd 操作。dd|l 操 作 和 library 
cache object 交 换 是 导致 Library cache load lock, library cache lock 和 library cache pin 的 主要 原因 。 在 row cache lock 中 涉及 dd| 的 措施 在 这 
里 使 用 都 合适 ， 在 row cache lock 中 涉及 shared pool 的 措施 在 这 里 也 都 合适 。 


keep 操 作对 row cache object 来 说 作用 有 限 ， 但 是 对 library cache object 来 说 作用 比较 大 。 另 外 ，library cache object 远 比 row cache 
object 来 得 复杂 ， 除 了 降低 锁 持 有 次 数 外 ， 降 低 锁 持 有 时 间 同 样 需要 考虑 。 


1. 降 低 library cache lock 锁 持 有 次 数 


降低 library cache lock 的 锁 资源 持 有 次 数 是 降低 冲突 、 提 高 性 能 的 基本 方法 ，row cache lock 中 罗列 的 方式 在 这 里 都 可 以 使 用 ， 下 面 重 点 介 
绍 keep 和 hard parse 的 影响 。 


(1) keep hot object， 避 免 library cache object 被 交换 出 去 


keep 操 作 是 管理 library cache 的 重要 工具 ， 它 可 帮助 我 们 把 hot library cache object 钉 在 内 存 中 ， 不 会 被 LRU 策 略 所 影响 。 通 过 把 library 
cache object 钉 在 内 存 中 ， 可 降低 由 于 LRU 清 理 及 重新 reload 需 要 的 library cache load lock, library cache lock 及 library cache pin, 


在 大 部 分 操作 中 ，library cache object 上 都 增加 了 null mode 的 library cache lock。 在 keep 之 后 ， 这 些 对 象 将 不 再 需要 加 载 library cache 
lock， 从 而 降低 了 锁 需求 。 


(2) 降低 hard parse 锁 资源 需求 


hard Parse 每 次 都 需要 对 cursor 引 用 的 library cache object 增 加 shared mode 的 library cache lock， 而 soft parse 则 仅 在 首次 的 时 候 需 要 持 
有 null mode， 后 续 的 soft pars 对 引用 对 象 根 本 不 需要 library cache lock 的 参与 。 两 者 之 间 对 library cache lock 的 参与 完全 处 于 不 同 的 数量 纪 
E 


2. 减 少 library cache lock 锁 资源 的 持 有 时 间 


减少 锁 持 有 时 间 的 基本 方法 是 更 多 的 keep 操 作 和 降低 hard parse。keep 操 作 可 避免 从 外 部 装载 ， 使 锁 持 有 时 间 变 短 。 而 hard parse 相 比 于 
soft parse 需 要 做 更 多 的 工作 ， 使 锁 操作 持 有 时 间 大 幅 增 加 。 


最 后 回顾 作用 于 row cache lock 优 化 的 方式 ， 降 低 ddl 操 作 和 保持 足够 大 小 的 shared pool， 这 同样 是 作用 于 library cache lock 的 基本 优化 工 
作 方 法 。 降 低 hard parse， 除 了 降低 锁 资源 需求 和 减少 锁 资 源 持 有 时 间 之 外 ， 另 外 一 个 重要 的 目标 就 是 可 以 有 效 帮 助 控 制 shared pool 大 小 ， 减 少 
library cache object 交 换 发 生 的 频率 。 


11.7 row cache lock 和 library cache lock 锁 资源 优化 案例 


1. 密 码 错 误导 致 数据 库 登 录 挂 起 


某 医 院 在 数据 库 修改 了 密码 和 业务 密码 配置 文件 之 后 ， 数 据 库 出 现 大 量 的 row cache lock 冲 突 ， 导 臻 数据库 挂 起 ， 遭 遇 Oracle bug 
7715339。 


2.nocache 的 sequence 导 臻 row cache lock 冲 突 


某 运 营 商 的 RAC 系 统 ， 在 业务 高 峰 期 出 现 较 多 的 row cache lock 冲 突 ， 冲 突 的 row cache 为 Sequence， 检 查 sequence 对 象 ， 其 
cachesize=0。 这 个 设置 是 为 了 保证 RAC 之 间 的 顺序 一 致 性 而 特意 设置 的 。 经 过 仔细 衡量 之 后 ， 还 是 cached+ordered 的 成 本 更 低 ， 同 时 keep 该 
sequence 以 避免 序列 跳 号 ， 基 本 接近 sequence nocache 的 效果 。 调 整 之 后 row cache lock 冲 突 事件 消失 ， 业 务 响应 恢复 。 


3.undo segment 频 繁 的 online 和 offline 引 起 row cache lock 冲 突 


某 运 营 商 出 现 enq: US. row cache lock 及 row cache objects lacth 冲 突 。row cache lock 发 现 dc rollback segments 和 engq: US 冲突 一 
致 ， 查 询 发 现 系统 中 存在 大 量 的 undo segment， 同 时 在 alert 文 件 中 发 现 频繁 的 online 和 offline undo segment 操 作 。 基 本 可 以 断言 是 由 于 频繁 
的 online 和 offline 引 起 的 enq: US 和 row cache lock 冲 突 。 设 置 10511 事 件 关闭 undo segment offline 功 能 ， 业 务 恢复 正常 。 


4.library cache lock 和 library cache latch 导 致 运行 缓慢 


某 运 营 商 RAC 系 统 中 的 一 个 节点 运行 缓慢 ， 表 现 为 大 量 的 library cache lock 和 library cache latch 冲 突 ， 用 户 确认 没有 什么 配置 变化 。 查 看 
free shared pool 似 乎 还 比较 多 ，flush shared pool 有 所 缓解 ， 但 很 快 又 出 现 类 似 情况 。 在 观察 了 flush shared pool 操 作 之 后 的 自由 空间 增长 状 
况 ， 以 及 shared pool 碎 片 情况 后 ， 确 定 为 shared pool 不 足 。 比 较 两 个 节点 的 shared pool， 发 现 参数 不 一 致 ， 用 户 确认 是 运 维 的 时 候 使 一 个 节点 
的 参数 变 小 了 ， 简 单 恢复 shared_pool size 参数 ， 业 务 恢 复 正 常 。 


5.SGA 区 域 动态 扩展 引起 和 hard parse 共 同 作用 


某 运营 商 出 现 library cache lock, latch: shared pool 和 latch: library cache 的 锁 与 latch 资 源 冲 突 。 确 认 有 新 业务 上 线 ，hard parse 明 显 偏 
。 查 看 SGA resize 操 作 ， 看 到 因 执 行 SGA resized 操 作 导 致 了 library cache lock 冲 突 。SGA 自 动 管理 在 高 并 发 性 环境 引起 性 能 问题 的 概率 非常 
， 特 别 是 在 hard parse 相 对 比较 高 的 环境 中 ， 而 hard parse 在 比较 高 的 环境 下 会 容易 导致 SGA resize, 


Jy R 


6.grant 操 作 引 起 library cache lock 及 library cache pin 等 待 


某 运营 商业 务 正常 运行 ， 但 是 对 客户 表格 做 了 一 个 grant 之 后 就 出 现 了 大 量 的 library cache lock 和 library cache pin， 部 分 业务 挂 起 ，grant 语 


句 也 挂 起 。 显 然 是 高 峰 期 的 ddl 导 致 业务 出 现 问题 ， 终 止 grant 语 句 之 后 ， 业 务 缓慢 恢复 。 


7. 进 程 ^C 中 断 引 起 的 library cache lock 等 待 


某 运 营 商 的 部 分 批 处 理 业务 运行 缓慢 ， 检 查 发 现 业务 在 等 待 ibrary cache lock， 似 乎 处 于 完全 挂 起 状态 。 检 查 拥塞 进程 ， 发 现 拥塞 进程 处 于 僵 
死 状态 。 依 据 程序 名 和 机 器 名 咨询 相关 人 员 ， 表 示 该 业务 为 临时 做 的 处 理 ， 由 于 执行 时 间 长 放弃 了 。 简单 kill 这 个 僵 死 进程 ， 业 务 恢复 。 进 程 ^C 中 
断 或 简单 关闭 客户 端 会 导致 Oracle 没 有 正确 认识 到 该 进程 已 经 被 中 断 或 者 放弃 ， 依 然 保持 在 活动 列表 中 ， 持 有 众多 的 资源 ， 自 然 就 阻塞 了 其 他 业务 


的 运行 。 
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某 运 营 商 在 业务 运行 过 程 中 突然 出 现 大 量 的 buffer busy waits 等 待 ， 同 时 伴随 着 很 多 cache buffers chains latch 冲 突 。 检 查 错误 日 志 ， 发 现 
正在 做 错误 dump， 操 作 系统 资源 内 存 紧 张 ， 频 繁 执行 交换 操作 。dump 完 成 之 后 ，buffer busy waits 等 待 消失 ， 业 务 恢复 正常 。 出 现 该 性 能 问题 
的 原因 在 于 大 文件 的 dump 消 耗 大 量 内 存 ，3 引 起 了 交换 ， 导 致 内 存 读 / 写 响 应 延迟 。 为 了 避免 coredump 之 类 的 操作 过 度 而 影响 系统 ， 可 调整 操作 系 
统 内 存 参 数 maxperm 以 限制 内 存 使 用 。 
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某 运 营 商 在 业务 运行 过 程 中 突然 出 现 大 量 的 buffer busy waits 等 待 ， 同 时 伴随 着 很 多 cache buffers chains latch 冲 突 。 检 查 错误 日 志 ， 发 现 
正在 做 错误 qump， 操 作 系统 资源 内 存 紧 张 ， 频 繁 执行 交换 操作 。dump 完 成 之 后 ，buffer busy waits 等 待 消失 ， 业 务 恢复 正常 。 出 现 该 性 能 问题 
的 原因 在 于 大 文件 的 dump 消 耗 大 量 内 存 ， 引 起 了 交换 ， 导 致 内 存 读 / 写 响应 延迟 。 为 了 避免 coredump 之 类 的 操作 过 度 而 影响 系统 ， 可 调整 操作 系 
统 内 存 参数 maxperm 以 限制 内 存 使 用 。 


12.2 buffer header 和 buffer lock (pin) 


为 了 避免 同时 修改 buffer block 或 者 读 取 不 一 致 的 数据 ， 需 要 在 访问 buffer block 的 时 候 获 取 buffer lock 或 者 buffer pin。 当 大 量 不 兼容 的 
buffer lock 需 求 申 请 发 生 ， 就 会 发 生 buffer lock 冲 突 ， 也 就 是 buffer busy waits 或 read by other session 冲 突 。 


需要 注意 的 是 ，buffer lock 并 不 是 锁 在 buffer block 之 上 的 ， 而 是 作用 在 buffer block header 之 上 的 ， 也 就 是 buffer block header list 中 的 
buffer header。Oracle 访 问 buffer block 的 基本 路 径 如 下 。 


1) 依据 数据 块 的 地 址 计算 出 数据 块 所 在 的 bucket。 


2) 保护 这 个 bucket 的 cbc latch。 


3) 在 这 个 链表 上 找寻 需要 的 数据 块 ， 找 到 后 ，pin 这 个 buffer ( 读 取 s， 修 改 x) ， 也 就 是 加 载 buffer lock。 如 果 buffer lock 无 法 兼容 ， 这 时 


会 报告 buffer busy waits。 
4) 释放 cbc latch, 
5) 读 取 / 修 改 数据 块 的 内 容 。 
6) 获取 cbc latch。 
7) unpin 这 个 buffer， 也 就 是 释放 buffer lock。 
8) 释放 cbc latch, 


这 个 过 程 清晰 地 表达 了 什么 时 候 需 要 获得 buffer lock， 什 么 时 候 会 出 现 buffer lock 冲 突 ， 也 就 是 buffer busy waits。 这 个 过 程 也 清晰 了 表明 
了 buffer busy waits 和 cache buffer chains latch wait 之 间 的 相关 性 。 


从 图 12-1 所 示 的 buffer header chain 可 以 看 出 ，buffer lock 就 是 作用 在 buffer header chain 中 的 一 个 特定 的 block header。 


DBA+Class 
Cache buffer chains:latch#1 


Hash Fun Bucket 1 


Cache buffer 


chains:latchz2 
Bucket 4 


Bucket 6 


Cache buffer 
chains:latch£3 Bucket 7 


Bucket 8 


图 12-1 buffer header list, cache buffer chain latch febuffer lock 


12.3 buffer lock 冲 突 的 简单 验证 
测试 数据 准备 ， 如 图 12-4 所 示 。 


SQL» create table a(id number,name varchar2(100)); 
Table created 


SQL» insert into a values (100, '10000'); 


1 row inserted 


SQL» commit; 
Commit complete 


图 12-4 测试 数据 准备 


12.4 buffer lock 运行 性 能 的 衡量 和 测量 


12.4.1 buffer lock) 中 突 的 buffer block 类 型 


buffer lock 属 于 并 发 性 资源 ， 也 就 是 说 ， 只 要 有 不 同 的 session 共 同 访问 相同 的 buffer block， 就 可 能 会 产生 buffer lock 冲 突 ， 特 别 是 在 更 新 
比较 频繁 的 buffer block 中 会 产生 buffer lock 冲 突 。 


1.data segment header 


data segment header 一 般 只 有 在 segment 变 化 的 时 候 才 会 进行 更 新 ， 比 如 extent 的 扩展 和 回收 、HWM 的 扩展 和 回收 、used block 和 free 
block 的 变化 。 也 就 是 说 ， 在 update 的 时 候 几 乎 不 会 发 生 data segment header 的 更 新 ， 而 只 有 在 insert 和 delete 操 作 的 时 候 才 会 发 生 。 而 查询 操 
作 、 索 引 扫 描 操作 不 会 涉及 data segment header 的 访问 ， 只 有 在 全 表 扫 描 中 才 会 涉及 。 


一 般 而 言 ， 在 业务 系统 中 除了 个 别 接口 表格 会 发 生 频 繁 的 insert 和 delete， 大 部 分 表格 实际 发 生 的 操作 都 为 insert 和 和 update。 也 就 是 data 
segment header 之 上 的 buffer lock 冲 突 主 要 会 在 insert 上 发 生 的 insert; 中 突 ， 个 别 业务 接口 表格 会 发 生 在 insert 和 delete 之 间 。 在 data segment 
header 中 很 少 会 发 生 查 询 和 更 新 之 间 的 buffer lock 冲 突 。 


2.undo segment header 


undo segment header 的 更 新 访问 除了 在 事务 开始 和 结束 之 外 ， 其 他 更 新 同 data segment header 一 样 ， 主 要 来 源 于 空间 的 扩展 。 而 在 
oracle 自 动 管 理 的 undo segment 中 ， 很 少 会 有 不 同事 务 同 时 作用 在 相同 的 undo segment 中 ， 也 就 是 说 ，undo segment header 在 不 同 的 
Session 更 新 操作 中 相对 很 少 发 生 。 但 是 查询 操作 的 CR 读 几 乎 每 次 读 都 会 涉及 undo segment header 的 访问 ， 也 就 是 说 ,undo segment header 
的 buffer lock 冲 突 主要 发 生 在 查询 和 更 新 之 间 。 


3.index segment header 


index segment header 的 情况 几乎 完全 等 同 于 data segment header。 当 然 ，index segment 还 会 发 生 素 引 分 裂 操作 ， 索 引 分 裂 事实 上 类 似 


于 空间 的 扩展 。 
4.BMB block 或 freelist block 


BMB block 或 freelist block 都 作用 于 段 自 由 空间 的 管理 ，BMB 作 用 于 ASSM freelist block 作 用 于 MSSM。 因 此 ，BMB block 和 freelist 
block 也 只 有 在 insert 和 delete 的 情况 下 才 会 涉及 。 


5.data block 


data block 是 buffer lock 的 发 生 目标 和 主体 部 分 ， 其 他 segment header 或 BMB block 等 之 所 以 会 存在 ， 是 因为 由 访问 data block 引 起 的 。 不 
同 于 其 他 block 的 buffer lock 会 发 生 在 特定 时 候 ， 而 data block 的 buffer lock 冲 突 发 生 在 可 能 的 任意 场景 下 ， 比 如 查询 | 查询 、 查 询 | 更 新 、 更 新 | 更 
新 等 不 同 的 场景 。 


6.undo block 
undo block 公 被 一 个 事务 所 有 ， 也 就 是 说 ， 更 新 进程 之 间 不 会 发 生 undo block 的 冲突 ， 只 有 查询 和 更 新 之 间 才 会 发 生 undo block 的 冲突 。 
7.index block 


index block 从 场景 上 来 看 可 能 是 最 易 发 生 buffer lock 的 场景 ， 由 于 index 总 是 比 表格 行 更 小 ， 因 此 在 每 个 index block 中 总 是 会 包含 更 多 的 
行 ， 也 就 是 说 ， 会 更 容易 造成 buffer lock 冲 突 。 昌 然 从 设计 上 考虑 ， 频 繁 update 的 字段 不 应 该 设置 索引 ， 但 是 insert 和 delete 总 是 会 引起 index 
block 的 buffer lock 锁 定 。 


12.5 buffer lock 锁 资源 优化 的 目标 和 道路 


buffer lock 冲 突 主 要 来 源 于 对 某 个 block 的 并 发 性 访问 ， 特 别 是 当 block 正 在 进行 更 新 的 时 候 进行 并 发 性 访问 。 显 然 ， 只 要 降低 block buffer 
lock 锁 资源 需求 的 并 发 度 或 加 速 block 的 访问 过 程 ， 就 可 以 有 效 降 低 buffer lock 的 冲突 。 


降低 block buffer lock 锁 资源 需求 的 并 发 度 可 以 从 以 下 两 个 角度 来 考虑 。 
- 降低 buffer lock 锁 资源 需求 。 
: 分散 局 部 热点 ， 降 低 bufferlock 的 并 发 性 。 
而 加 速 buffer block 的 访问 过 程 只 需要 避免 内 存 访问 速度 下 降 就 可 以 完成 。 


read by other session 冲 突 本 质 上 就 是 buffer lock 冲 突 ， 我 们 也 一 并 在 这 里 描述 。 


12.6 buffer lock 锁 资源 优化 案例 


1.MSSM 段 在 计 费 类 (RAC) 应 用 中 的 性 能 障碍 


某 运营 商 在 Oracle RAC 中 的 两 个 不 同 节点 同时 计 费 入 库 总 是 无 法 得 到 满意 的 实时 计 费 性 能 ,会 出 现 大 量 gc buffer busy 等 待 事件 ， 导 致 入 库 响 
应 缓慢 。 表 格 为 MSSM 表 格 ， 未 执行 有 效 的 分 区 。 可 以 在 表格 中 增加 一 个 instance 字 段 ， 并 依据 该 字段 进行 分 区 。 这 样 处 理 后 ， 每 个 RAC 节 点 的 计 
费 就 入 库 到 了 自己 独占 的 egment 中 ， 不 同 节点 之 间 的 入 库 计 费 就 不 会 产生 入 库 环节 的 冲突 ， 也 就 是 说 ,没有 gc buffer busy T. 


采用 有 效 分 区 是 一 种 简单 的 处 理 方式 ， 在 MSSM 中 利用 freelist group 也 可 以 完成 以 上 目标 ， 而 ASSM 基 本 不 会 发 生 上 述 问题 。 虽 然 如 此 ， 在 
实践 中 ， 日 志 类 应 用 采用 freelist group 或 者 ASSM 没 有 很 好 的 效果 ， 原 因 很 简单 ， 表 格 上 可 能 有 索引 ， 而 索引 数据 是 排序 的 ， 冲 突 是 不 可 避免 的 。 
这 时 ， 唯 一 解决 buffer lock 冲 突 的 方法 就 是 分 区 ， 让 冲突 的 索引 分 区 到 不 同 的 索引 段 中 。 


2. 日 志 切 换 过 于 频繁 导致 buffer busy waits 和 log buffer space 等 待 


某 工商 管理 局 间歇 性 地 出 现 log buffer space 和 buffer busy waits) 中 突 ， 查 询 日 志 几 乎 每 10 秒 钟 产 生 一 个 归档 日 志 。Oracle 在 归档 日 志 切 换 过 
程 中 |gwr 进 程 将 停止 工作 ，log buffer 总 是 被 持续 的 数据 流 填 充 而 导致 log buffer space 冲 突 ， 由 于 log buffer space 冲 突 而 使 buffer lock 持 有 时 
间 过 长 ， 导 致 buffer busy waits 冲 突 。 检 查 |gwr 进 程 本 身 效率 足够 ， 是 因为 online redo logfile 设 置 为 默认 的 5MB， 只 需 更 新 online redo logfile 
大 小 为 2GB， 业 务 便 恢复 正常 。 


3. 由 于 read by other session 导 致 业务 系统 挂 起 


某 公安 系统 产生 大 量 read by other session， 业 务 基本 挂 起 。 检 查 发 现 read by other session 事 件 的 p1 和 p2 不 会 发 生变 动 ， 也 就 是 
i, holding p1 和 kp2 的 数据 块 的 进程 处 于 挂 起 或 者 空转 状态 或 者 信号 通知 没有 到 达 。 通 过 p1 和 p2 查 找 DB file scatter read 和 DB file sequential 
read 事 件 ， 找 到 holding session， 果 然 挂 起 在 持续 读 取 p1.p2 数 据 块 。 尝 试 通过 kill-3 重 新 激活 进程 ， 在 接 到 kill-3 命 令 之 后 ，holding session 被 激 
活 ， 业 务 重新 恢复 正常 。 
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131 简单 案例 分 享 


某 运营 商 的 客服 系统 在 业务 高 峰 的 时 候 发 生 大 量 row cache objects latch 冲 突 ， 导 致 客服 响应 延迟 甚至 阻塞 。 通 过 flush shared_pool, 该 问 
题 有 所 缓解 ， 但 是 很 快 又 到 达 高 峰 ， 即 使 重新 启动 数据 库 ， 也 很 快 会 达到 高 峰 ， 从 而 导致 业务 系统 阻塞 。 但 是 ， 只 要 度 过 了 高 峰 期 ， 业 务 系统 就 会 
恢复 正常 。 业 务 系统 表现 出 了 相对 较 高 的 SQL version， 涉 及 高 版 本 的 SQL 语 句 普 遍 引 用 公共 同义词 ， 而 公共 同义词 的 引用 ， 依 据 经 验 会 使 [ow 
cache object latch 访 问 次 数 大 幅度 增加 。 将 代码 修复 为 owner.table 访 问 之 后 ， 该 阻塞 问题 得 到 解决 。 


latch free 是 大 家 在 日 常 性 能 处 理 过 程 中 遇 到 的 最 为 主要 的 性 能 障碍 之 一 ， 其 中 比较 多 的 latch 有 : library cache, shared pool, row cache 


objects、cache buffers chains 等 。 
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某 运营 商 的 客服 系统 在 业务 高 峰 的 时 候 发 生 大 量 row cache objects latch 冲 突 ， 导 致 客服 响应 延迟 甚至 阻塞 。 通 过 flush shared pool, 该 问 
题 有 所 缓解 ， 但 是 很 快 又 到 达 高 峰 ， 即 使 重新 启动 数据 库 ， 也 很 快 会 达到 高 峰 ， 从 而 导致 业务 系统 阻塞 。 但 是 ， 只 要 度 过 了 高 峰 期 ， 业 务 系统 就 会 
恢复 正常 。 业 务 系统 表现 出 了 相对 较 高 的 SQL version， 涉 及 高 版 本 的 SQL 语句 普遍 引用 公共 同义词 ， 而 公共 同义词 的 引用 ， 依 据 经 验 会 使 row 
cache object latch 访 问 次 数 大 幅度 增加 。 将 代码 修复 为 owner.table 访 问 之 后 ， 该 阻塞 问题 得 到 解决 。 


latch free 是 大 家 在 日 常 性 能 处 理 过 程 中 遇 到 的 最 为 主要 的 性 能 障碍 之 一 ， 其 中 比较 多 的 latch 有 : library cache, shared pool, row cache 


objects、cache buffers chains 等 。 


13.2 ”并 发 性 控制 资源 : latch 或 spinlock 


关于 latch 或 spinlock，http://andreynikolaev.wordpress.com 网 站 已 经 做 了 很 多 介绍 。 对 于 latch 或 spinlock， 有 兴趣 的 读者 可 以 参考 这 个 网 
站 的 相关 文章 。 这 里 主要 是 对 latch 或 者 spinlock 进 行 简单 的 描述 。 


latch、spinlock， 轻 量 的 旋转 锁 ， 顾 名 思 义 ， 即 通过 spin 来 获得 latch。latch 或 spinlock 是 用 来 保护 Oracle 的 内 存 结构 的 ， 可 通过 latch 控 制 对 
Oracle 的 内 存 结构 进行 串 行 化 访问 。 


13.3 ” latch 的 spin 和 spin_count 控 制 


13.3.1 latch 的 spin 和 spin_count 控 制 


latch 又 表述 为 spinlock，spinlock 的 获得 就 是 因为 spin 过 程 的 存在 。spin 过 程 是 Oracle 进 程 以 最 快速 度 获得 latch 的 基本 保证 ， 不 过 ， 在 spin 过 
程 中 ， 因 为 不 释放 CPU 资源 ， 所 以 会 导致 消耗 大 量 CPU。Oracle 期 望 latch 的 获得 速度 和 持 有 时 间 都 可 以 在 极 短 时 间 内 完成 ， 这 也 是 spin 过 程 存 在 
的 基本 原因 。 一 般 来 说 ，latch 的 获得 和 处 理 都 要 在 微 秒 的 范畴 完成 ， 而 lock 则 一 般 在 ms 级 别 完成 。spin 机 制 的 好 处 在 于 某 些 热门 的 业务 应 用 几乎 
总 是 可 以 快速 地 获得 latch (通过 牺牲 冷门 的 process 来 完成 ) 。 


1.spin_count 参 数 


spin 是 获得 latch 的 一 个 基本 过 程 ， 设 置 一 个 恰当 的 spin_count 是 保持 latch 高 效 运行 的 关键 所 在 。 过 大 的 spin_count 会 无 效 地 消耗 大 量 的 CPU 
资源 ， 过 小 的 spin_count 则 会 导致 latch 获 得 延迟 ， 使 业务 响应 变 慢 。 可 以 用 图 13-5 的 方式 获得 spin_count 人 参数 配置 值 。 


SQL» SELECT  ksppinm,ksppstvl,ksppdesc 
2 FROM xS$ksppi JOIN x$ksppcv USING (indx,inst id) 
3 WHERE ksppinm = ' spin count' 
4 / 

KSPPINM KSPPSTVL KSPPDESC 


Spin count 


图 13-5 ”获得 spin_count 参 数 的 值 


spin_count 的 默认 值 为 2000， 该 参数 可 以 动态 进行 调整 。 但 是 ， 从 Andrey Nikolaev 的 研究 成 果 来 看 ，_spin_count 的 动态 调整 仅 会 对 shared 
latch 生 效 ， 而 对 于 library cache, shared pool 等 exclusive latch 来 说 ，_spin_count 的 动态 调整 并 不 会 产生 效果 。 也 就 是 说 ，exclusive latch 的 


spin_count 是 静态 的 。 
2. 如 何 设置 latch 的 spin_count 


Exclusive latch 运 行 时 spin_count 并 不 是 由 _spin_count 参 数控 制 的 ， 而 是 由 存储 在 x$ksllclass 的 spin 参 数控 制 的。 比如 在 笔者 的 Oracle 数 据 库 
中 有 如 图 13-6 所 示 的 情况 。 


SQL» select indx,spin from x$ksllclass; 


0 
1 
2 
3 
4 
5 
6 
7 


图 13-6 ”spin_count 由 spin 参 数控 制 


笔者 的 Oracle 数 据 库 并 没有 设置 spin_count， 如 果 动 态 变 更 spin_count 会 发 生 什 么 变化 。 从 图 13-7 可 以 看 到 ， 动 态 变 更 spin_count 并 不 会 
使 x$ksllclass 的 值 发 生变 化 。 但 是 在 重新 启动 数据 库 之 后 ，_spin_count 被 设置 到 了 x$ksllclass 中 。 
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当 不 同 进程 访问 共同 的 内 存 结构 时 ， 就 可 能 会 出 现 latch 冲 突 。Oracle 在 SGA 中 存在 着 众多 的 内 存 结构 ， 因 此 也 就 需要 众多 不 同 的 latch 保 护 
了 。 从 图 13-13 所 示 的 截图 可 以 看 到 ， 在 笔者 的 Oracle 11gR2 数 据 库 中 有 535 个 不 同 的 latch， 而 整个 内 存 结构 则 更 是 被 高 达 6105 个 latch 进 行 保 
护 。 


SQL» select count(*) from v$latch parent; 
COUNT (*) 


SQL» select count(*) from v$latch children; 
COUNT (*) 


6105 


113-13 latch 的 资源 情况 


13.5 主要 的 latch 资 源 场景 和 冲突 


13.5.1 Cache buffers chains latch 


Cache buffers chains: latch 属 于 共享 自 旋 锁 ， 其 作用 在 Buffer header list 之 上 。 对 于 共享 锁 来 说 ， 最 为 关键 的 问题 在 于 清楚 在 哪些 场合 下 
需要 获得 exclusive 模 式 的 latch。 从 buffer lock 章 节 可 以 知道 ， 为 了 访问 buffer block， 需 要 获得 两 次 cache buffers chains latch。 图 13-27 简 单 
表示 了 Cache buffer chains latch 和 Buffer header list 之 间 的 关系 。 


DBA+Class 
Cache buffer chains:latch# 1 


Hash Fun Bucket 1 


Bucket 2 


Cache buffer 


chains:latchz2 
Bucket 4 


Bucket 6 


Cache buffer 


chains:latch£3 Bucket 7 


Bucket 8 


图 13-27 Cache buffer chains latch 和 buffer header list 


CBC (cache buffer chains) latch 作 用 在 buffer header link list 之 上 ， 显 然 只 有 在 buffer header link 增 加 或 者 减少 buffer header 时 才 会 产 
生 exclusive mode 的 需求 。 下 面 来 看 看 在 哪些 场合 下 需要 获得 exclusive mode 的 latch。 


4—3 


1. 全 表 扫 描 中 的 CBC latch 行 为 


segment header 中 包含 了 自由 空间 和 HWM 信 息 ， 在 全 表 扫描 以 及 update、delete、insert 操 作 中 都 需要 访问 segment header。 在 测试 验证 
中 ， 可 发 现在 不 同 的 Oracle 版 本 里 其 表现 也 是 不 同 的 ， 趋 势 应 该 是 共享 模式 的 CBC 场 景 会 越 来 越 多 。 


Oracle 11.2.0.1for Windows, 访问 段 头 获得 独占 模式 的 CBC latch， 其 他 block 共 享 模式 获得 CBC latch, 
Oracle 10.2.0.1for Linux， 访 问 段 头 获得 独占 模式 的 CBC， 访 问 其 他 block 同 样 是 获得 独占 模式 的 CBC latch, 
Oracle 10.2.0.5for Linux， 访 问 段 头 获得 独占 模式 的 CBC latch， 访 问 其 他 block 同 样 是 获得 独占 模式 的 CBC latch, 


Oracle 11.2.0.4for Linux， 访 问 段 头 获得 共享 模式 的 CBC latch， 其 他 block 同 样 获得 共享 模式 的 CBC latch, 


下 面 看 看 在 Oracle 11.2.0.4 和 10.2.0.1 中 的 测试 ， 如 图 13-28 所 示 。 


SQL» create table a (id number ,name varchar2(30)); 
Table created. 

SQL> insert into a values(1,100); 

1 row created. 


SQL> commit; 


Commit complete. 


SQL> select * from a; 


SQL> select data object id from user objects where object name-'A'; 


DATA, OBJECT. ID 


0000000078931768 
87382 


000000007 BA0D380 
87382 


图 13-28 ”在 11.2.0.4 和 10.2.0.1 中 的 测试 
(1) Oracle 11.2.0.4for Linux 


session 1: 以 共享 模式 对 段 头 持 有 CBC， 如 图 13-29 所 示 。 


SQL> oradebug setmypid 

Statement processed. 

SQL> oradebug call kslgetsl.w 0x00000000789317681 1 1 8 
Function returned 1 

soL- B 


图 13-29 ”以 共享 模式 对 段 头 持 有 CBC 


session 2: 查询 不 受阻 塞 ， 表 示 总 是 由 共享 模式 持 有 ， 如 图 13-30 所 示 。 


SQL> select * from a; 


图 13-30 ”查询 不 受阻 塞 


(2) Oracle 10.2.0.1for Linux 


session 1: 在 segment header 上 持 有 共享 的 CBC latch， 如 图 13-31 所 示 。 


SQL» oradebug poke 0x000000007D25CC50 4 0x01 
BEFORE: [07D25CC50, 07D25CC54) - 00000000 
AFTER: [07D25CC50, 07D25CC54) = 00000001 


SQL» oradebug peek 0x000000007D25CC50 4 
[07D25CC50, 07D25CC54) = 00000001 
SQL> J 


图 13-31 在 segment headet 上 持 有 共享 的 CBC latch 


session 2: 发 布 查询 ， 发 现 挂 起 ， 如 图 13-32 所 示 。 


Connected to: 
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production 
With the Partitioning, OLAP and Data Mining options 


SQL» select * from a; 
加 


图 13-32 发布 查询 ， 发 现 挂 起 
session 3: 查看 等 待 在 什么 地 方 ， 也 就 是 在 哪 等 待 持 有 的 CBC latch 释 放 ， 如 图 13-33 所 示 。 
SQL» select sid,event,plraw,p2,p3 from v$session where sid-1099; 


SID EVENT 


1099 latch: cache buffers chains 
000000007D25CC50 122 0 


SQL> B 


图 13-33 ”查看 等 待 的 位 置 
session 4: 释放 CBC latch。 不 知道 为 什么 ， 一 旦 其 他 session 发 布 访问 ， 拥 有 的 共享 CBC 就 会 被 升级 成 独占 的 CBC latch， 如 图 13-34 所 示 。 


session 5: 在 session 1 释放 CBC latch 之 后 ， 查 询 结束 挂 起 ， 如 图 13-35 所 示 。 


SQL» oradebug poke 0x000000007D25CC50 4 0x00 
BEFORE: [07025CC50, 07D25CC54) = 000000FF 


AFTER:  [07D25CC50, 07D25CC54) = 00000000 
SQL> f 


图 13-34 ”释放 CBC latch 
SQL» select * from a; 


ID NAME 


1 180 


图 13-35 ”查询 结束 挂 起 


非 段 头 的 数据 块 全 表 扫 描 可 以 采用 同样 的 方法 测试 。 
2. 索 引 扫 描 中 的 CBC latch 行 为 
知道 了 在 全 表 扫 描 中 的 CBC latch 行 为 ， 表 来 看 看 索引 扫描 的 情况 。 具 体 的 测试 过 程 就 不 重复 了 ， 这 里 仅 给 出 结论 。 
Oracle 10.2.0.1: index block 需 要 获得 exclusive CBC latch， 不 管 是 否 是 唯一 索引 。 
Oracle 10.2.0.5: leaf index block 需 要 获得 exclusive CBC latch， 其 他 shared CBC latch, 
Oracle 11.2.0.1: 所 有 的 index block 获 得 shared CBC latch, 


3.new block 


new block 主 要 包含 两 种 类 型 : 物理 读 和 HWM 扩 展 。new block 需 要 在 Buffer header list 中 增加 节点 ， 显 然 需要 exclusive CBC latch 的 参 
与 。 


4.CR block 


CR block 的 增加 等 同 于 new block, CR block 的 重用 应 该 不 会 产生 exclusive mode 的 CBC latch 需 求 。 由 于 CR block 只 为 一 次 读 取 服务 ， 存 
在 一 个 max CR block 的 限制 ， 因 此 CR block 重 用 并 不 会 影响 CBC link， 按 理 说 不 需要 获得 exclusive mode 的 latch。 但 是 不 幸 的 是 ， 从 测试 验证 的 
结果 来 看 ， 任 何 CR 块 生成 都 需要 获得 exclusive CBC latch。 测 试 如 下 : 


session 1: 更 新 行 记录 ， 使 后 续 的 查询 都 采用 CR 读 并 持 有 shared CBC， 如 图 13-36 所 示 。 


SQL> update a set name-2000 where id-1; 


1 row updated. 


SQL» oradebug call kslgets]l w 0x0000000078BA0D380111 8 
ORA-00074: no process has been specified 

SQL» oradebug setmypid 

Statement processed. 

SQL> oradebug call kslgetsl w 0x000000007BA0D380111 8 
Function returned 1 

SQL> 


图 13-36 更 新 行 记录 


session 2: 执行 CR 查询 挂 起 ， 如 图 13-37 所 示 。 


SQL> select * from a where id-1; 


图 13-37 执行 CR 查询 挂 起 
在 达到 max cr 之 后 的 CR 读 依 然 会 采用 exclusive CBC, 
session 1: 持 有 shared CBC， 如 图 13-38 所 示 。 


session 2: 执行 查询 依然 挂 起 ， 如 图 13-39 所 示 。 


SQL> select hladdr,dbarfil,dbablk,class,state,tch from x$bh where obj-87382; 
HLADDR DBARFIL DBABLK 


000000007B931768 
000000007BA0D3B0 
000000007BA0D3B0 
000000007BA0D3B0 
000000007BA0D3B0 
000000007BA0D3B0 
000000007BA0D3B0 


het et pe pet jt jet 
H H H t Ht jt 
NH HH HH o 


7 rows selected. 


SQL» oradebug call cade w 0x000000007BA0D380111 8 
Function returned 1. 


图 13-38 ”查询 CBC latch 并 手动 持 有 


SQL- select * from a where id-1; 


图 13-39 ”执行 查询 依然 挂 起 


5. 更 新 (update, deletefllinsert) 


在 清晰 了 CR 的 读 都 需要 exclusive CBC 之 后 ， 自 然 就 知道 update 和 delete 都 需要 exclusive CBC 了 。 期 望 insert 操 作 采 用 shared CBC 的 也 没有 


发 生 ， 也 就 是 任何 对 于 块 的 更 新 操作 都 需要 exclusive CBC 的 参与 。 


当 通 过 索引 对 表格 进行 更 新 的 时 候 ， 表 格 的 数据 块 总 是 会 获得 exclusive CBC， 但 是 索引 除了 leaf block 之 外 ， 其 他 的 index block 都 会 采用 
shared CBC 获 得 。 


6.LRU 活 动 


LRU 活 动 会 不 断 地 访问 buffer header List， 自 然 也 就 需要 CBC latch 的 参与 了 。 从 前 面 的 描述 可 以 知道 ， 只 要 涉及 数据 块 的 变化 ， 必 然 会 涉及 


exclusive CBC latch, 


7.smon 清 理 


smon 在 很 多 场合 下 需要 对 buffer header link 进 行 清理 。 比 如 Drop table, Truncate table 等 操作 引起 的 local checkpoint 等 ， 该 操作 完成 后 
需要 从 缓存 中 把 相关 的 Block 清 理 掉 ， 清 理 的 过 程 自然 就 要 从 buffer header link 中 进行 摘除 。smon 对 事务 的 清理 也 会 涉及 CBC latch 的 释放 ， 这 
时 自然 也 需要 exclusive mode 了 。 


13.6 ”latch 资源 运行 性 能 的 衡量 


latch 资 源 的 性 能 主要 通过 以 下 指标 来 衡量 。 
(1) latch 的 请 求 次 数 (latch gets per second) 

latch gets: latch gets 为 最 重要 的 latch 资 源 指标 ， 表 示 作用 在 latch 之 上 的 输入 压力 和 吞吐 量 。 
(2) latch 的 请 求 丢 失 次 数 (latch misses per second) 

latch misses: 每 秒 钟 latch gets 请 求 失败 的 次 数 ， 该 数值 一 般 和 latch gets 密 切 正 相关 。 
(3) latch 的 请 求 成 功率 (latch gets ratio per second) 


latch gets ratio per second=latch gets/ (latch gets+latch misses) ，latch gets 的 请 求 成 功率 可 以 表示 在 latch 资 源 上 的 冲突 程度 。 一 般 
来 说 需要 达到 99% 以 上 。 


(4) latch 的 spin 请 求 次 数 (latch spin gets per second) 
latch spin gets per second: latch 请 求 通过 spin gets 方 式 获得 的 请 求 次 数 。 
(5) latch 的 睡眠 次 数 (latch sleeps per second) 


latch sleeps per second: 当 通 过 spin 方 式 无 法 获取 时 ， 就 进入 sleep 状 态 ， 每 进入 一 次 就 计算 一 次 sleeps。sleep 状 态 也 就 是 进入 真正 的 latch 
free 等 待 状态 。 


(6) latch 请 求 丢 失 进 入 睡眠 率 (latch sleep ratio) 
latch sleep ratio=latch sleeps/latch misses。 有 多 少 次 latch misses 进 入 了 sleep， 表 示 无 法 在 spin 周 期 内 获得 。 
(7) latch 请 求 丢失 的 spin 获 得 率 (latch spin ratio) 


latch spin ratiozlatch spin gets/latch misses， 表 示 spin gets 在 latch misses 中 获得 的 比例 。 比 例 越 高 ， 表 示 spin gets 越 有 效 ， 比 例 越 低 ， 
意味 着 spin_count 的 参数 不 是 很 合理 。 


(8) latch 等 待 时 间 (latch wait time per gets) 


latch wait tiem per gets: 每 次 latch gets (包括 spin gets) 的 等 待 时 间 。 


(9) latch sleep 等 待 时 间 (latch wait time per sleep) 
latch wait time per sleep: 每 次 latch sleep 所 花费 的 等 待 时 间 。 
(10) 最 大 等 待 时 间 (maxWaitTime) 
maxWaitTime: 最 长 latch 请 求 等 待 时 间 ， 锁 性 能 事故 的 发 布 往往 不 是 由 平均 等 待 决定 的 ， 而 是 由 最 大 等 待 决定 的 。 
以 下 指标 与 buffer cache 的 latch 资 源 有 关 。 
1) 逻辑 读 次 数 (logical reads per second) 。logical reads per second 表 示 每 秒 逻 辑 |/O 的 次 数 。 


2) 块 变化 数量 (block changes per second) 。block changes per second 表 示 每 秒 数据 块 变化 的 数量 。 


13.7 latch 资 源 优化 的 目标 和 道路 


latch 的 冲突 主要 来 源 于 对 某 个 内 存 保护 对 象 的 并 发 性 访问 ， 特 别 是 shared latch 的 exclusive 模 式 访问 ， 更 容易 引起 冲突 。 对 于 任何 并 发 性 资 
源 ， 其 资源 优化 的 方式 几乎 总 是 相同 的 ， 不 外 乎 是 以 下 三 种 不 同方 法 。 


1. 降 低 latch 并 发 性 资源 需求 


每 个 latch 都 需要 在 特定 的 条 件 下 获得 ， 比 如 shared pool latch 只 有 在 分 配 和 回收 空间 的 时 候 才 需要 。 在 实践 中 ， 只 要 通过 优化 降低 这 些 需要 
latch 的 场合 ， 自 然 就 降低 了 对 latch 资 源 的 需求 。 


2. 分 布 latch 并 发 性 资源 


对 于 高 并 发 性 的 latch，Oracle 采 用 多 种 children latch 的 方式 来 提高 并 发 性 。 大 多 数 情况 下 ， 大 量 的 latch 需 求 集中 在 某 几 个 子 latch 中 ， 这 时 
可 以 通过 适当 的 手段 把 请 求 分 布 到 不 同 的 latch 中 ， 分 散热 点 ， 使 latch 资 源 的 需求 均衡 。 


3. 降 低 latch 资 源 的 持 有 时 间 


降低 latch 资 源 的 持 有 了 时间， 就 可 以 提高 latch 的 并 发 性 吞吐 量 。 降 低 latch 资 源 的 持 有 时 间 和 降低 latch 请 求 次 数 是 一 个 硬币 的 两 面 ， 都 可 以 有 效 
地 达成 latch 资 源 的 优化 。 


13.8 latch 资 源 优化 案例 


1. 虚 拟 内 存 配置 不 当 引 起 大 量 cache buffers chains 


某 社保 局 出 现 大 量 的 cache buffers chains 和 buffer busy waits; 中 突 ， 同 时 可 以 看 到 library cache 和 shared pool latch 的 冲突 。 检 查 SQL 响 应 
感觉 逻辑 读 偏 慢 ，SGA 配 置 比较 高 ， 配 置 24GB， 基 本 判断 是 虚拟 内 存 问 题 。 检 查 虚 拟 内 存 统计 ， 发 现 频 繁 的 大 量 页 面 交换 。 简 单 降低 SGA 区 到 
16GB，cache buffers chains 以 及 其 他 latch 冲 突 消失 。 


2.Shared pool| 不 足 和 碎片 化 导致 大 量 的 library cache 


某 运营 商 的 RAC 系 统 ， 一 个 节点 正常 ， 另 一 个 节点 出 现 大 量 的 library cache latch 冲 突 ， 伴 生 部 分 shared pool 以 及 row cache objects 冲 突 。 
咨询 用 户 确认 没有 发 生 任 何 变化 ， 检 查 shared pool 空 闲 达 到 2GB 甚 至 以 上 ,但 是 subpool 的 碎片 化 比较 严重 。 基 本 判断 为 shared pool 
ig, flush shared pool 之 后 持续 观察 shared pool 的 变化 ， 最 终 确 定 为 shared pool 不 足 引起 该 问题 。 对 照 另 一 个 节点 的 shared pool 配 置 ， 发 现 该 
节点 比 另 一 个 节点 少 2GB， 此 为 之 前 临时 调整 的 ， 但 是 忘记 调整 回来 。 恢 复 配 置 ， 业 务 恢复 正常 。 


3. 由 于 hard parse 引 起 大 量 的 library cache 和 shared pool 


某 运 营 商 在 早 高 峰 时 候 出 现 大 量 的 library cache 和 shared pool 冲 突 ， 通 过 awr 发 现 hard parse 偏 高 ， 已 经 越过 机 器 处 理 的 临界 点 。 和 用 户 确 
认 是 否 存在 新 业务 上 线 ， 用 户 确认 昨 晚 有 新 业务 上 线 ， 新 增加 的 hard parse 都 来 源 于 新 业务 。 交 由 业务 厂商 修改 代码 ， 采 用 绑 定 变量 降低 hard 


parse。 


4.SGA 动 态 扩 展 引起 大 量 的 library cache 和 shared pool 冲 突 


某 运营 商 出现 大 量 的 library cache latch 和 shared pool latch 冲 突 ， 在 几 分 钟 之 后 业务 恢复 正常 。 检 查 SGA 动 态 扩展 信息 ， 发 现在 响应 缓慢 期 
间 出 现 SGA 区 动态 扩展 。 在 SGA 区 动态 扩展 期 间 ，shared pool 被 长 期 持 有 ， 因 此 就 会 导致 ibrary cache latch 和 shared pool latch 的 冲突 。 为 了 
减少 动态 扩展 的 发 生 ， 设 置 最 小 的 shared poo| 为 足够 大 的 数值 。 


5. 高 版 本 输出 不 确定 造成 大 量 的 row cache objects latch 


某 社保 局 业务 系统 出 现 大 量 的 row cache objects latch 冲 突 ， 检 查 发 现存 在 大 量 的 高 版 本 SQL， 而 且 SQL 高 版 本 具有 无 限 增加 的 特性 。 由 于 
vpd 输 出 不 确定 引起 每 条 语句 的 SQL 版 本 不 断 增 加 ， 每 次 都 需要 重新 生成 执行 计划 ， 导 致 row cache objects 的 需求 大 幅度 增加 。 修 正 vpd 输 出 使 其 
稳定 ，SQL 高 版 本 消失 ， 业 务 恢复 正常 。 


6.remote dblink 访 问 引起 row cache objects latch 


某 运营 商 出 现 大 量 row cache objects latch 冲 突 ， 检 查 发 现 冲 突 的 row cache 为 dc_histogram_data， 确 定 引 起 冲突 的 语句 都 来 源 于 dblink 访 
问 。 从 AWR 中 可 以 发 现 ， 存 在 大 量 执行 次 数 为 零 但 是 parse calls 次 数 极 高 的 语句 ， 这 表示 来 自 于 dblink 的 语句 存在 某 种 重新 parse 现 象 。 通 过 比较 
分 析 了 解 到 ， 同 样 的 业务 不 通过 dblink 访 问 都 不 会 存在 问题 ， 没 有 dc _histogram_data 的 访问 需求 。 由 于 无 法 确定 是 Oracle 特 征 还 是 bug， 简 单 通 
过 设置 event 10129 事 件 禁 止 remote query 访 问 柱状 图 信息 ，row cache objects 的 访问 量 急 剧 下 降 ，row cache objects 的 冲突 也 就 消失 了 。 


7. 大 型 事务 意外 终止 导致 undo global data latch 冲 突 


某 运营 商 意 外 出 现 大 量 的 undo global data latch 冲 突 ， 业 务 响应 变 慢 。 检 查 等待 undo global data 的 语句 均 为 查询 语句 ， 分 布 在 不 同 的 表格 
中 ， 也 就 是 全 局 阻塞 ， 这 个 特征 比较 符合 undo global data latch 的 现象 。 检 查 大 型 事务 和 回 滚 ， 发 现 有 一 个 大 型 事务 回 滚 正 在 发 生 ， 开 始 时 间 点 
也 和 业务 响应 缓慢 相 匹 配 。 由 于 勉强 可 以 执行 业务 ， 所 以 等 待 事务 结束 。 在 大 型 事务 回 滚 结束 后 ，undo global data latch 冲 突 消失 ， 业 务 恢 复 正 


p 
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8.o0bject queue header operation latch 和 DRM 


某 运营 商 的 RAC 系 统 响 应 很 慢 ， 甚 至 于 挂 起 或 者 crash。 检 查 Ims 进 程 日 志 ， 发 现 其 频繁 等 待 object queue header operation latch。 同 时 发 
现 drm 操 作 非 常 活跃 。Ims cache fusion 操 作 总 是 要 获得 object queue header operation latch， 简 单 关闭 drm 降 低 Ims 对 object queue header 
operation latch 的 需求 ， 业 务 系统 恢复 正常 。 


第 14 章 ”资源 供给 : mutex 


14.1 简单 案例 分 享 


某 商 业 银行 业务 系统 在 高 峰 期 的 CPU 的 消耗 很 高 ， 但 有 些 CPU 消 耗 特别 高 的 进程 总 发 生变 化 ， 业 务 系统 基本 还 可 以 响应 。 在 CPU Time 表 现 
Fh, parse CPU 相对 比较 高 ，hard parse 不 高 ， 系 统 偶尔 出 现 cursor pin: S, v$mutex sleep_history 表 现 出 较 高 的 gets 和 sleeps。 综 合 判 断 为 
mutex 的 机 制 冲 突 引起 ， 应 用 patch: 6904068 之 后 CPU 消耗 快速 降低 ， 当 然 性 能 是 不 会 增加 的 ， 只 是 释放 了 CPU 资源 。 


很 幸运 ，Oracle 在 很 多 地 方 采用 mutex 来 蔡 代 latch。 由 于 mutex 的 并 发 性 处 理 能 力 远 远 高 于 latch， 所 以 mutex 带 来 的 问题 变 少 。 但 是 ， 在 简 


化 性 能 的 同时 也 带 来 了 副作用 ， 针 对 mutex 问 题 的 可 优化 余地 很 小 。 
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很 幸运 ，Oracle 在 很 多 地 方 采用 mutex 来 蔡 代 latch。 由 于 mutex 的 并 发 性 处 理 能 力 远 远 高 于 latch， 所 以 mutex 带 来 的 问题 变 少 。 但 是 ， 在 简 
化 性 能 的 同时 也 带 来 了 副作用 ， 针 对 mutex 问 题 的 可 优化 余地 很 小 。 


14.2 并 发 性 控制 资源 : mutex 


关于 mutex，http://andreynikolaev.wordpress.com 网 站 已 经 做 了 很 多 介绍 ， 有 兴趣 的 人 可 以 参考 该 网 站 的 相关 文章 。 这 里 不 可 能 比 该 网 站 
论述 得 更 好 ， 仅 对 mutex 做 些 简单 的 描述 。 


mutex， 也 可 以 认为 是 一 种 更 加 轻 量 级 的 latch， 作 用 于 latch 的 思路 完全 可 以 作用 mutex。 两 者 的 区 别 在 于 : mutex 是 内 存 结构 本 身 包含 的 ， 
随 着 内 存 的 分 配 而 分 配 、 销 毁 而 销毁 ，latch 则 是 一 种 独立 的 内 存 结构 ， 使 用 这 种 独立 的 内 存 结构 去 保护 library cache hash bucket 等 内 存 结构 。 
同样 基于 这 个 特征 ， 你 会 发 现 mutex 的 作用 粒度 要 远 远 高 于 latch， 因 为 latch 结 构 要 消耗 160 字 节 ， 其 处 理 效率 只 有 优先 的 latch 数 量 ， 需 要 保护 的 
内 存 结构 自然 就 比较 多 。 由 于 mutex 内 置 的 特征 ， 其 保护 的 内 存 结构 几乎 是 最 细 粒 度 的 ， 所 以 其 并 发 性 、 支 持 性 要 好 于 latch。 


与 shared latch 一 样 可 使 mutex 用 CAS 方 法 获得 和 释放 latch， 在 实践 中 完全 可 以 把 它 看 成 是 一 种 shared latch， 只 是 其 粒度 更 细 ， 更 加 轻 量 
级 。 按 照 http://andreynikolaev.wordpress.com 的 观点 ，mutex 采 用 spin+FIRO 策 略 ， 而 shared latch 采 用 spin+FIFO 策 略 。 


Oracle 10gR2 采 用 mutex 蔡 代 library cache pin latch, Oracle 11gR2 采 用 mutex 蔡 代 library cache latch。 本 章 主 要 采用 Oracle 119R2, íi 
别 是 11.2.0.2 之 后 的 版 本 。 


143 ”mutex 对 应 的 wait event 说 明和 场景 


14.3.1 ”mutex 对 应 的 wait eventi 


14-9 中 的 语句 可 以 简单 说 明 mutex 涉 及 等 待 事件 的 意义 。 
其 中 : 
“ idn: 唯一 的 mutex 标 记号 ， 对 应 于 library cache object 的 hash_value。 可 以 利用 这 个 idn 获 得 造成 冲突 的 library cache objecto 
: value: blocking SID |shared refs。 高 位 4 字 节 包含 拥有 exclusive mutex 的 sid。 低 位 字 节 为 shared 引 用 的 计数 。 


- where: location ID|sleeps。 高 位 4 字 节 包含 冲突 的 位 置 。 低 位 字 节 包含 sleep 的 次 数 。 


SQL> select name,parameteri,parameter2,parameter3 from v$event name 
2 where name like '%cursor%' or name like '%mutex%'; 


PARAMETE PARAMETE PARAMETER3 
SecurerFile mutex 


cursor: mutex x 
cursor: mutex S 


cursor: pin X 

cursor: pin S 

cursor: pin S wait on X 
library cache: mutex x 

library cache: mutex S 


8 rows selected. 


图 14-9 ”mutex 事 件 及 其 参数 意义 


144 ”mutex 资 源 ; 中 突 和 性 能 优化 


在 性 能 优化 过 程 中 ， 完 全 可 以 把 mutex 作 为 一 种 特殊 的 latch 来 考虑 ， 采 用 mutex 对 应 的 latch 类 型 的 优化 方式 来 进行 mutex 资 源 冲 突 的 优化 。 


145 “主要 的 mutex 资 源 场景 和 冲突 


14.5.1 cursor pin mutex 
cursor pin mutex 蔡 换 了 原先 的 latch: library cache pin， 除 了 采用 mutex 机 制 来 替代 exclusive latch 机 制 以 外 ， 其 他 方面 并 没有 太 大 的 差 
别 。 因 此 cursor pin mutex 的 资源 需求 场景 和 library cache pin latch 相 同 。 具 体 描述 请 参见 latch 资 源 相关 章节 ， 这 里 仅 描 述 两 者 之 间 的 差异 。 


cursor pin mutex 采 用 CAs 机 制 实现 ， 这 与 library cache pin latch 采 用 TAS 机 制 有 明显 的 不 同 。 相 比 于 TAS 机 制 ，CAS 机 制 具有 更 高 的 并 发 
性 ， 从 而 使 cursor pin mutex 发 生 冲突 的 概率 大 幅 降 低 。 另 外 ，library cache pin latch 的 数量 也 是 有 限 的 ， 也 就 是 说 ,不 同 的 cursor 可 能 会 发 生 
library cache pin 冲 突 。 而 cursor pin mutex 定 位 于 每 个 不 同 的 cursor， 也 就 是 说 ， 只 有 相同 的 cursor 才 有 可 能 发 生 cursor pin mutex 冲 突 。 


对 于 cursor pin mutex 而 言 ， 主 要 会 发 生 cursor: pin S, cursor: pin X 以 及 cursor: pin S wait X 等 冲突 性 事件 。 绝 大 部 分 情况 下 ，cursor 
pin 都 以 shared 方 式 获得 ， 只 有 在 hard parse 或 者 reload 的 情况 下 才 需要 cursor pin 以 exclusive 方 式 获得 。 


从 latch 章 节 可 以 知道 ，no parse 对 于 library cache pin latch 的 需求 最 少 ，hard parse 对 于 library cache pin latch 的 需求 最 多 ， 高 版 本 的 SQL 
会 大 幅 增加 library cache pin latch 的 需求 。 这 些 知识 和 经 验 同 样 适 用 于 cursor pin mutex 的 场景 。 
REA Ea 3 
14.6 ”mutex 资 源 的 运行 性 能 衡量 和 测量 


14.651. mutex 资源 运行 性 能 衡量 的 主要 指标 


mutex 资 源 的 性 能 主要 通过 以 下 指标 来 衡量 。 


1) mutex 的 请 求 次 数 (mutex gets per second) 。 


mutex gets: mutex gets 是 最 为 重要 的 mutex 资 源 指标 ， 表 示 作 用 在 mutex 之 上 的 输入 压力 和 吞吐 量 


o 


2) mutex 的 请 求 失败 次 数 (mutex sleeps per second) 。 

mutex sleeps per second: 当 通 过 spin 方 式 无 法 获取 之 后 ， 就 进入 sleep 状 态 。sleep 状 态 就 是 进入 真正 的 各 种 mutex 等 待 状态 。 
3) mutex 请 求 成 功率 (mutex get ratio) 。 

mutex gets ratio=mutex gets/ (mutex gets+mutex sleeps) ， 在 进入 sleep 之 前 成 功 获得 mutex 的 比率 。 
4) mutex 等 待 时 间 (mutex wait time per gets) 。 

mutex wait time per gets=mutex wait time/mutex gets。 每 次 mutex gets (包括 spin gets) 的 等 待 时 间 。 
5) mutex sleep 等 待 时 间 (mutex wait time per sleep) 。 

mutex wait time per sleep=mutex wait time/mutex sleeps。 每 次 latch sleep 所 花费 的 等 待 时 间 。 

6) 最 大 等 待 时 间 (maxWaitTime) 。 

maxWaitTime: 最 长 latch 请 求 等 待 时 间 ， 锁 性 能 事故 的 发 布 往往 不 是 由 平均 等 待 决定 的 ， 而 是 由 最 大 等 待 决定 。 
以 下 指标 和 mutex 资 源 相关 。 

1) parse 次 数 (parse calls per second) 。 

parse calls: 每 秒 SQL 分 析 的 次 数 。 

2) hard parse 次 数 (hard parse calls per second) 。 

hard parse calls: 每 秒 硬 分 析 的 次 数 。 

3) 高 版 本 parse calls (high version parse calls per second) 。 

high version calls per second: 通过 高 版 本 的 SQL 方式 进行 parse 的 次 数 。 

4) shared pool 自 由 空间 (shared pool free memory) 。 

shared pool free memory: shared pool 的 自由 总 空间 大 小 。 

5) library cache 请 求 次 数 (library cache gets per second) 。 

library cache gets per second: 每 秒 library cache 请 求 的 次 数 。 

6) library cache pin 请 求 次 数 (library cache pins per second) 。 

library cache pins per second: 每 秒 library cache pin 的 请 求 次 数 。 

7) library cache pin reload 次 数 (library cache reload pins per second) 。 

library cache reload pins per second: 每 秒 library cache pin 需 要 通过 reload 方 式 获得 的 请 求 次 数 。 

8) library cache pin 请 求 成 功率 (library cache pins ratio per second) 。 


library cache pins ratio per second=1-library cache pin reloads/library cache pins， 每 秒 library cache pins 的 请 求 成 功率 。 


14.7 ”mutex 资 源 优化 的 目标 和 道路 


可 以 认为 mutex 是 一 种 轻 量 级 的 latch， 工 作 方式 基本 相似 。 可 以 采用 类 似 于 latch 资 源 优化 的 方法 来 进行 mutex 资 源 的 优化 。 


1. 降 低 mutex 并 发 性 资源 需求 


每 个 mutex 都 要 在 特定 的 条 件 下 才能 获得 ， 比 如 获得 cursor parent mutex 的 exclusive 只 有 在 分 配 或 者 释放 cursor 的 时 候 才 需要 。 实 践 中 ， 只 
要 通过 优化 减少 了 这 些 需要 mutex 的 场合 ， 就 降低 了 对 mutex 资 源 的 需求 。 


2. 分 布 mutex 并 发 性 资源 


3. 减 少 mutex 资 源 的 持 有 时 间 


减少 mutex 资 源 的 持 有 时 间 ， 就 可 以 提高 mutex 的 并 发 性 吞吐 量 。 减 少 mutex 资 源 的 持 有 时 间 和 mutex 请 求 次 数 是 一 个 硬币 的 两 面 ， 都 可 以 有 
效 达 成 mutex 资 源 优化 的 目标 。 


14.8 mutex spin count, sleep time、scheme 和 mutex 和 资源 优化 


对 于 mutex 资 源 优化 来 说 ，mutex_spin_count 会 成 为 一 个 常见 的 优化 选择 项 。mutex_spin_count 表 示 在 获取 mutex 失 败 之 后 在 线 自 旋 多 少 
次 ,以 不 断 请 求 mutex 资 源 ， 该 参数 的 默认 值 为 255。 从 实践 的 角度 考虑 ，mutex_spin_count 的 参数 值 比较 低 ， 特 别 是 在 11.2.0.2 之 后 的 版 本 。 在 
11.2.0.2 以 下 版 本 中 ， 如 果 没 有 应 用 补丁 6904068， 则 mutex_spin_count 的 值 关系 不 大 。 


从 图 14-4 的 比较 报告 可 以 看 出 ， 默 认 值 mutex_spin_count=255 明 显 偏 小 ， 设 置 值 在 1000~2000 之 间 是 相对 合理 的 范畴 。 建 议 总 是 调整 


mutex spin count- 1000, 


sheme 的 工作 模式 默认 为 2， 也 就 是 采用 最 小 CPU 消耗 偏好 ， 采 用 与 传统 latch 工 作 方式 类 似 的 模式 工作 。 如 果 业 务 系统 的 CPU 资源 相对 比较 充 
分 则 scheme 2 并 不 是 最 合适 的 工作 模式 。 


对 于 CPU 资源 充分 的 系统 ， 设 置 更 小 的 sleep time 会 有 更 好 的 性 能 和 更 高 的 吞吐 量 ， 比 如 1ms。 具 体 比较 参见 图 14-35。 
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图 14-35 CPU 资源 充分 的 环境 下 mutex_wait_time 不 同 设 置 的 吞吐 量 影 响 


当然 ， 如 果 你 的 系统 有 高 度 的 并 发 性 ，CPU 资 源 相 对 比较 紧张 ， 则 sleep_time 会 有 更 高 的 吞吐 量 。 具 体 比 较 参 见 图 14-36。 
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图 14-36 CPU 资源 场景 下 _mutex_wait_time 的 不 同 设置 的 吞吐 量 响应 


14.9 ” ”mutex 资源 优化 案例 


1.dblink 失 效 导致 的 cursor: pin S wait on X 


某 运营 商 客 户 账 务 数据 库 计 划 从 Oracle 10g 升 级 到 Oracle 11gR2， 并 迁移 至 新 的 主机 和 存储 上 。 升 级 迁移 完成 后 ， 在 主机 各 项 资源 都 充足 的 
情况 下 ， 业 务 测试 阶段 即 出 现 大 量 的 cursor: pin S wait on X 等 待 事件 (无 法 修改 数据 库 隐 含 参数 kks_use_mutex_pin 回 到 传统 的 latch 保 护 ) . 
经 过 检查 发 现 ， 工 程 师 在 迁移 数据 库 时 ， 忘 记 将 tnsnames.ora 拷 贝 至 新 的 生产 主机 ， 导 致 部 分 dblink 失 效 。dblink 恢 复 正常 后 ，cursor: pin S 
wait on X 等 待 事件 消失 。 事 后 查 明 ， 数 据 库 可 能 命中 bug 9472669'cursor: pin S wait on X'waits for invalid SQL over DB link, 


2.shared pool 过 大 导致 出 现 大 量 的 mutex 争 用 


某 省 统计 局 数据 库 从 原来 的 32GB 内 存 主机 迁移 至 256GB 内 存 主 机 之 后 ， 实 例 运行 一 周 左右 即 规律 性 地 出 现 大 量 mutex 争 用 ，mutex 争 用 平均 
等 待 时 间 为 好 几 百 毫秒 ， 业 务 几 乎 停止。 刷新 shared pool 之 后 症状 有 所 缓 减 。 经 过 仔细 检查 ， 在 SGA 配 置 为 120GB 的 情况 下 ，shared pool 自 动 
扩展 到 100GB 左 右 。 根 据 实 践 经 验 ， 统 计 业务 并 不 需要 这 么 大 的 shared pool 空 间 。 解 决 方法 也 很 简单 : 关闭 SGA 内 存 自 动 调整 ， 并 将 shared 
pool 大 小 控制 在 5GB。 数 据 库 性 能 恢复 正常 并 稳定 运行 。 


3.high version count 导 致 出 现 大 量 ORA-600 [17059] 错误 


某 新 华 书 店 网 站 数据 库 后 台 警 告 日 志 出 现 大 量 的 ORA-600 [17509] 错误 ， 查 询 v$session_wait 视 图 出 现 大 量 的 Cursor: pin S on X 等 待 事 
件 。 经 过 查看 AWR 报 告发 现 ， 有 大 量 的 SQL version count， 高 达 5000 多 ， 这 是 极 不 正常 的 。 事 后 检查 发 现 ， 数 据 库 命 中 Oracle bug， 打 上 补丁 
8922013 之 后 ， 数 据 库 性 能 恢复 正常 。 


